#zephyr — Public Fediverse posts

I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

I really need to work out a better way to include libraries into #Zephyr applications. My current setup (using projects in a West manifest, and then a bunch of CMake mumbo-jumbo feels wrong). Perhaps using FetchContent?

Icy Electronics nRF54L15 Discovery devboard integrates a snappable nRF52820 CMSIS-DAP debugger

https://fed.brid.gy/r/https://www.cnx-software.com/2026/07/23/icy-electronics-nrf54l15-discovery-devboard-integrates-a-snappable-nrf52820-cmsis-dap-debugger/

https://www.europesays.com/africa/340976/ Zephyr Receives Notice of Rejection of Zimbabwe EPO Applications #applications #epo #Notice #rejection #zephyr #zimbabwe

Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

Note that all of this worked, and as far as I can tell, nothing on my side changed, and it suddenly didn't work any more. Yet, if I look at the commits from the last few weeks, I don't see anything that would indicate any possible area. #Zephyr

It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

And yet, there it is (nm -C):

utils.cpp.obj:
00000000 T coherent::utils::get_random_uint8(unsigned char)
00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
00000000 T coherent::utils::get_random_uint8()
00000000 T coherent::utils::get_random_uint32(unsigned int)
00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
00000000 T coherent::utils::get_random_uint32()

What, for the love of Zeus, is going on here? #Zephyr

It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

And yet, there it is (nm -C):

utils.cpp.obj:
00000000 T coherent::utils::get_random_uint8(unsigned char)
00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
00000000 T coherent::utils::get_random_uint8()
00000000 T coherent::utils::get_random_uint32(unsigned int)
00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
00000000 T coherent::utils::get_random_uint32()

What, for the love of Zeus, is going on here? #Zephyr

It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

And yet, there it is (nm -C):

utils.cpp.obj:
00000000 T coherent::utils::get_random_uint8(unsigned char)
00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
00000000 T coherent::utils::get_random_uint8()
00000000 T coherent::utils::get_random_uint32(unsigned int)
00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
00000000 T coherent::utils::get_random_uint32()

What, for the love of Zeus, is going on here? #Zephyr

It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

And yet, there it is (nm -C):

utils.cpp.obj:
00000000 T coherent::utils::get_random_uint8(unsigned char)
00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
00000000 T coherent::utils::get_random_uint8()
00000000 T coherent::utils::get_random_uint32(unsigned int)
00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
00000000 T coherent::utils::get_random_uint32()

What, for the love of Zeus, is going on here? #Zephyr

It seems like it should *only* be in libapp.a, so why is it ending up in libzephyr.a? Shouldn't that *just* be OS-level code, and not anything from my code?

And yet, there it is (nm -C):

utils.cpp.obj:
00000000 T coherent::utils::get_random_uint8(unsigned char)
00000000 T coherent::utils::get_random_uint8(unsigned char, unsigned char)
00000000 T coherent::utils::get_random_uint8()
00000000 T coherent::utils::get_random_uint32(unsigned int)
00000000 T coherent::utils::get_random_uint32(unsigned int, unsigned int)
00000000 T coherent::utils::get_random_uint32()

What, for the love of Zeus, is going on here? #Zephyr

OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

.../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

But why? I have one of these in the application CMakeLIst.txt:

add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

Then in the coherent-common, I have this in CMakeList.txt:

if(CONFIG_COHERENT_COMMON)
zephyr_library_sources(src/utils.cpp)
zephyr_include_directories(include)
endif()

Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

#Zephyr

OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

.../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

But why? I have one of these in the application CMakeLIst.txt:

add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

Then in the coherent-common, I have this in CMakeList.txt:

if(CONFIG_COHERENT_COMMON)
zephyr_library_sources(src/utils.cpp)
zephyr_include_directories(include)
endif()

Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

#Zephyr

OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

.../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

But why? I have one of these in the application CMakeLIst.txt:

add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

Then in the coherent-common, I have this in CMakeList.txt:

if(CONFIG_COHERENT_COMMON)
zephyr_library_sources(src/utils.cpp)
zephyr_include_directories(include)
endif()

Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

#Zephyr

OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

.../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

But why? I have one of these in the application CMakeLIst.txt:

add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

Then in the coherent-common, I have this in CMakeList.txt:

if(CONFIG_COHERENT_COMMON)
zephyr_library_sources(src/utils.cpp)
zephyr_include_directories(include)
endif()

Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

#Zephyr

OK, this is the thing that's happening again... maybe I didn't fix it? First, the error (tweaked to reduce lots of noise)

.../ld.bfd: zephyr/libzephyr.a(utils.cpp.obj): in function `coherent::utils::get_random_uint8(unsigned char, unsigned char)':
/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: multiple definition of `coherent::utils::get_random_uint8(unsigned char, unsigned char)'; app/libapp.a(utils.cpp.obj):/Users/petrilli/workspace/foo/lib/coherent-common/src/utils.cpp:22: first defined here

Which, as best as I can unravel, means that for some reason, Cmake put the utils.cpp.obj compiled file into two different libraries, and then tried to link them together. Yes, that seems bad.

But why? I have one of these in the application CMakeLIst.txt:

add_subdirectory_ifdef(CONFIG_COHERENT_COMMON ../../lib/coherent-common coherent-common)

That should look at the configuration, and add the top-level directory to all the search paths. Great, that's working just fine it seems.

Then in the coherent-common, I have this in CMakeList.txt:

if(CONFIG_COHERENT_COMMON)
zephyr_library_sources(src/utils.cpp)
zephyr_include_directories(include)
endif()

Again, I'm being super careful right now with not using any globbing. What's even more confusing is... this is triggered even if I never include the header file and never call any functions in the library. It *should* be pruning all that out in the process.

#Zephyr

@azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

So I can't figure out why it thinks the RNG is broken?

But since it looks like the problem is now in #Zephyr misunderstanding result codes?

Computers were a mistake.

@azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

So I can't figure out why it thinks the RNG is broken?

But since it looks like the problem is now in #Zephyr misunderstanding result codes?

Computers were a mistake.

@azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

So I can't figure out why it thinks the RNG is broken?

But since it looks like the problem is now in #Zephyr misunderstanding result codes?

Computers were a mistake.

@azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

So I can't figure out why it thinks the RNG is broken?

But since it looks like the problem is now in #Zephyr misunderstanding result codes?

Computers were a mistake.

@azonenberg so, single stepping through the code, the RNG comes up, the entropy sources are running, all the conditioning is working, it's dropping 32b into RNG_DR (the data register), that's constantly changing ..

So I can't figure out why it thinks the RNG is broken?

But since it looks like the problem is now in #Zephyr misunderstanding result codes?

Computers were a mistake.

Norik Systems introduces nRF9151-based USB Dongle for DECT NR+ deployments

https://fed.brid.gy/r/https://www.cnx-software.com/2026/07/09/norik-systems-introduces-nrf9151-based-usb-dongle-for-dect-nr-deployments/

Mercedes-Benz hosts open-source hardware Automotive Rapid DEvelopment Platform (ARDEP)

ARDEP (Automotive Rapid DEvelopment Platform) is an open-source hardware and software platform hosted on Mercedes-Benz’s GitHub account and…
#Germany #DE #Europe #EU #Europa #Mercedes-Benz #Automotive #crowdsupply #developmentboard #kicad #motorcontrol #OpenSource #stm32 #zephyr
https://www.europesays.com/germany/49818/

Mercedes-Benz hosts open-source hardware Automotive Rapid DEvelopment Platform (ARDEP)

https://fed.brid.gy/r/https://www.cnx-software.com/2026/07/07/mercedes-benz-hosts-open-source-hardware-automotive-rapid-development-platform-ardep/

I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

Much to think about.

I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

https://www.lispbm.com/pages/lispbm-zephyros-repl/

I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

Much to think about.

I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

https://www.lispbm.com/pages/lispbm-zephyros-repl/

I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

Much to think about.

I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

https://www.lispbm.com/pages/lispbm-zephyros-repl/

I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

Much to think about.

I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

https://www.lispbm.com/pages/lispbm-zephyros-repl/

I wonder what it would take to get LispBM running along side #Zephyr as an extension/scripting layer? There is an example that is walked through, but I feel like this is just using Zephyr as the bottom layer and not as a peer.

Much to think about.

I'd honestly like to use Micropython, but it's just too porky. Performance is fine, but if I'm gonna blow that much memory, I might as well use wasm and let someone bring whatever they want.

https://www.lispbm.com/pages/lispbm-zephyros-repl/

XIAO nRF54LM20A (Sense) board enables ultra-low-power Bluetooth 6.0, Matter, Thread, Zigbee, or 2.4 GHz proprietary applications

https://fed.brid.gy/r/https://www.cnx-software.com/2026/06/30/xiao-nrf54lm20a-sense-board-enables-ultra-low-power-bluetooth-6-0-matter-thread-zigbee-or-2-4-ghz-proprietary-applications/

XIAO nRF54LM20A (Sense) board enables ultra-low-power Bluetooth 6.0, Matter, Thread, Zigbee, or 2.4 GHz proprietary applications

https://web.brid.gy/r/https://www.cnx-software.com/2026/06/30/xiao-nrf54lm20a-sense-board-enables-ultra-low-power-bluetooth-6-0-matter-thread-zigbee-or-2-4-ghz-proprietary-applications/

XIAO nRF54LM20A (Sense) board enables ultra-low-power Bluetooth 6.0, Matter, Thread, Zigbee, or 2.4 GHz proprietary applications

https://web.brid.gy/r/https://www.cnx-software.com/2026/06/30/xiao-nrf54lm20a-sense-board-enables-ultra-low-power-bluetooth-6-0-matter-thread-zigbee-or-2-4-ghz-proprietary-applications/

XIAO nRF54LM20A (Sense) board enables ultra-low-power Bluetooth 6.0, Matter, Thread, Zigbee, or 2.4 GHz proprietary applications

https://web.brid.gy/r/https://www.cnx-software.com/2026/06/30/xiao-nrf54lm20a-sense-board-enables-ultra-low-power-bluetooth-6-0-matter-thread-zigbee-or-2-4-ghz-proprietary-applications/

Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. https://radar.offseq.com/threat/cve-2026-8023-improper-limitation-of-a-pathname-to-c30c7b8fffb254ad #OffSeq #Zephyr #Infosec #PathTraversal

Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. https://radar.offseq.com/threat/cve-2026-8023-improper-limitation-of-a-pathname-to-c30c7b8fffb254ad #OffSeq #Zephyr #Infosec #PathTraversal

Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. https://radar.offseq.com/threat/cve-2026-8023-improper-limitation-of-a-pathname-to-c30c7b8fffb254ad #OffSeq #Zephyr #Infosec #PathTraversal

Zephyr HTTP server (4.0.0 – 4.4.x) is affected by CVE-2026-8023 (HIGH): improper path handling enables unauthenticated remote file access via path traversal (../). Patch status unclear — check advisories & restrict exposure. https://radar.offseq.com/threat/cve-2026-8023-improper-limitation-of-a-pathname-to-c30c7b8fffb254ad #OffSeq #Zephyr #Infosec #PathTraversal

Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. https://radar.offseq.com/threat/cve-2026-10646-use-after-free-in-zephyrproject-zep-22335ff5e2d4e43d #OffSeq #Zephyr #CVE #Security

Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. https://radar.offseq.com/threat/cve-2026-10646-use-after-free-in-zephyrproject-zep-22335ff5e2d4e43d #OffSeq #Zephyr #CVE #Security

Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. https://radar.offseq.com/threat/cve-2026-10646-use-after-free-in-zephyrproject-zep-22335ff5e2d4e43d #OffSeq #Zephyr #CVE #Security

Zephyr 4.0.0 – 4.4.0 is affected by CVE-2026-10646 (HIGH, CVSS 7.4): use-after-free in getaddrinfo() can cause memory corruption via spoofed DNS responses. Patch pending — limit untrusted network access. https://radar.offseq.com/threat/cve-2026-10646-use-after-free-in-zephyrproject-zep-22335ff5e2d4e43d #OffSeq #Zephyr #CVE #Security

CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. https://radar.offseq.com/threat/cve-2026-10643-bounds-in-zephyrproject-zephyr-e3c8c9055812b105 #OffSeq #Zephyr #CVE202610643 #infosec

CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. https://radar.offseq.com/threat/cve-2026-10643-bounds-in-zephyrproject-zephyr-e3c8c9055812b105 #OffSeq #Zephyr #CVE202610643 #infosec

CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. https://radar.offseq.com/threat/cve-2026-10643-bounds-in-zephyrproject-zephyr-e3c8c9055812b105 #OffSeq #Zephyr #CVE202610643 #infosec

CVE-2026-10643: Zephyr (3.6.0 – 4.4.0) HIGH severity bug enables out-of-bounds kernel heap writes via recvmsg() with IP_PKTINFO. Local users can exploit for memory corruption or escalation. Patch pending — check advisories. https://radar.offseq.com/threat/cve-2026-10643-bounds-in-zephyrproject-zephyr-e3c8c9055812b105 #OffSeq #Zephyr #CVE202610643 #infosec

Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

Come hangout with me and chat @zephyr if you're in the Austin, TX area: https://www.zephyrproject.org/what-to-expect-at-the-zephyr-project-meetup-june-25-2026-in-austin-texas/

#zephyr #embedded

And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.

And now I have a choice to make... do I rewrite the stm32c5x.c handling of flash erase for #Zephyr to properly account for the EDATA flash (starting at 0x0840 0000), or just "lose" 64K of flash on the chip?

So weird that ST submitted the code originally (2025-12-16) but it doesn't fully support this part of the chip? That's a lot of storage on an embedded chip to leave on the table.

I'm just trying to figure out if there's more that needs to be done than just passing LL_FLASH_ERASE_EDATA_AREA instead in erase_page()?

I think the root of the problem is that I'm not sure how Zephyr deals with multiple different flashes on the same SOC? EDATA is different with either 1.5K or 2K page sizes (versus 8K), depending on some register bits (EDATASEL), so while it's contiguous with the rest of the flash, it isn't the same.

This may be why it isn't supported... because Zephyr doesn't seem to have a really clear way to implement this.

Gonna stew on this. Right now, I can burn other flash for configuration storage, but I resent having that much space wasted for no reason.