Problem with fstorage and ble active in Release mode

RE: Problem with fstorage and ble active in Release mode

Simonr — Tue, 31 Mar 2026 06:05:44 GMT

Correct, this was done with the "Build and Run" call. I did not change anything, but did test on a development kit. If you are seeing this issue when flashing on a custom board, I'd recommend trying on the nRF52832 DK to make sure whether this is only occurring on the custom board or if you see the same behavior on a DK as well.

Best regards,

Simon

RE: Problem with fstorage and ble active in Release mode

Stebitt — Mon, 30 Mar 2026 10:08:55 GMT

Hi Simon - thanks for this.

I assume this test has been done with the code compiled as Release and downloaded to the device with 'Build and Run'.
Did you have to modify or exclude anything on my code to make it run?

Can you please confirm?

This behavior is how I expect it should run. But on my device I have the issue described. Could it be that I have some conflicts with interrupts or modules which are active and lead to a 'hanging' in run-time? With my tests I can proof that not one byte is being written to the flash - if it is a 'hanging' then it happens right at the beginning.

Thanks for your support - I really need it.

Stephan

RE: Problem with fstorage and ble active in Release mode

Simonr — Mon, 30 Mar 2026 07:45:22 GMT

Hi Stephan

No I did not, but I did just now on my end. Please see the readout from the address where the device names are here. Sorry for the weird names, but there are a lot of devices around the office, so I have to name them something I remember to find them when searching. Device name was changed from "ostepop" to "flexboi".

PS C:\ncs\nrf-bm\v1.0.0> nrfutil device read --address 0x0007D000 --bytes 1000
682030708
0x0007D000: 6574736F 00706F70 00003041 00000000   |ostepop.A0......|
0x0007D010: 00000000 00000000 00000000 00000000   |................|
0x0007D020: 44414544 46454542 0C0B0A00 100F0E0D   |DEADBEEF........|
0x0007D030: 14131211 18171615 1C1B1A19 201F1E1D   |............... |
0x0007D040: 24232221 28272625 2C2B2A29 302F2E2D   |!"#$%&'()*+,-./0|
0x0007D050: 34333231 38373635 3C3B3A39 403F3E3D   |123456789:;<=>?@|
0x0007D060: 44434241 00000000 00000000 00000000   |ABCD............|
0x0007D070: 00000000 00000000 00000000 01451401   |..............E.|
0x0007D080: 78656C66 00696F62 00003041 00000000   |flexboi.A0......|
0x0007D090: 00000000 00000000 00000000 00000000   |................|
0x0007D0A0: 44414544 46454542 0C0B0A00 100F0E0D   |DEADBEEF........|
0x0007D0B0: 14131211 18171615 1C1B1A19 201F1E1D   |............... |
0x0007D0C0: 24232221 28272625 2C2B2A29 302F2E2D   |!"#$%&'()*+,-./0|
0x0007D0D0: 34333231 38373635 3C3B3A39 403F3E3D   |123456789:;<=>?@|
0x0007D0E0: 44434241 00000000 00000000 00000000   |ABCD............|
0x0007D0F0: 00000000 00000000 00000000 01451401   |..............E.|
0x0007D100: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF   |................|

Best regards,

Simon

RE: Problem with fstorage and ble active in Release mode

Stebitt — Fri, 27 Mar 2026 15:34:40 GMT

Hi Simon - thanks for your effort you made.

Have you explicitly checked and can you confirm that when programmed with 'Build and Run' the new name (actually the whole 128 byte package of the struct 'dev_block.info') is being written to the flash on a following start address in the same flash page? See the red marked 128 byte block under g) in my previous description from March 23rd.
Siede note: in a page is space for 32 blocks of 128 byte; we use only 31 blocks.

The problem is not that the new name is not immediately adopted for BT advertising without a restart. Our issue is that the new name or data is not written into the flash memory in this mode.

Best
Stephan

RE: Problem with fstorage and ble active in Release mode

Simonr — Fri, 27 Mar 2026 10:14:38 GMT

Hi Stephan

Sorry I didn't get back to you yesterday.

I have done some more testing now, and tried writing and reading the device name characteristic from the nRF Connect for Mobile app, and that seems to work. The Device name (characteristic data) does not change before the device has been reset though, which is expected, since the Bluetooth controller (SoftDevice) needs to reinitialize with the new name for it to take effect, so that might be what you're seeing here.

It still seems to behave the same in debug mode and release mode to me. Where it advertises for a short amount of time upon starting where I can connect to it and stay connected for as long as I want. The service and characteristic works as expected from what I can see, where you need to uninit and reinitialize the application for the device name changes to take effect. I'm also able to reconnect after connecting -> changing the device name -> resetting the device -> reconnect.

You say you do "Build and debug" and see the name is not changed. This is expected, as that would mean you flash the application with the original device name again when flashing the device in debug mode again. So it's also expected that the registers wouldn't change when you flash the device before going into debug mode.

Best regards,

Simon

RE: Problem with fstorage and ble active in Release mode

Stebitt — Thu, 26 Mar 2026 09:16:13 GMT

Hi Simon - do you have any news? we have a milestone meeting this afternoon and any info would be helpful...

Coming back to my question earlier in this topic: could you provide code where BT communication and fstorage runs in compiled mode. Then we could add our application step by step to it.

Best

Stephan

RE: Problem with fstorage and ble active in Release mode

Simonr — Wed, 25 Mar 2026 10:04:26 GMT

Sorry, I did not get to testing this further yet. I will follow your instructions and look further into this today. I'll get back to you with more details on Friday at the latest.

Best regards,

Simon

RE: Problem with fstorage and ble active in Release mode

Stebitt — Tue, 24 Mar 2026 14:50:17 GMT

Hi Simon - have you seen my comment? and did it help?

RE: Problem with fstorage and ble active in Release mode

Stebitt — Mon, 23 Mar 2026 14:55:20 GMT

Hi Simon - thanks for your time.

Yes, you have to do these steps:

a) download the program in debug mode (Build and Debug):

b) starting/running the program

c) pause the running program and check the flash memory starting at 0x007D000 to 0x007DFFF for last stored entry.
The data set (128 bytes) starts with the device name, here it is 'Flex 014' and 'Flex 015' .

d) reset and restart the program (still in debug mode)

e) establish a connection with the device (I use a mobile with nRF Connect) and open the service / UUID 'c8d1-e700.....'

f) send a 'Name change' command --> this is the characteristics 'c8d1-e710....' and write a new name in ASCII (I usually increase just the number of e.g 'Flex 008'. The name has to be 6 characters in minimum)

g) pause the running program and check the flash memory again
- -> the name should be written to the flash (here in red)

h) Now download the code in mode 'Build and Run' and do the step e) -> 'connect' has to be done within few seconds after download completes.

i) now send again a 'Name change' command (see f) above) with increased number for identification of new write to flash. On my side, the connection will get lost after this.

j) download the program in debug mode (Build and Debug) and do b) and c) again to check if the new name has been written. --> this never happend on our devices.

I hope this description guides you well and you can reproduce the issue we observe.
Feel also free to call me to assist you if you have any questions: +41 672 7530

Best

Stephan

RE: Problem with fstorage and ble active in Release mode

Simonr — Mon, 23 Mar 2026 12:58:36 GMT

I have your project running now, but I'm struggling to see what exactly you want us to debug here. It seems like the project behaves in the same way in release and debug mode to me. I was able to connect to the board both in release and debugging (once I removed the breakpoint). Do I need to do something specific to trigger/reproduce this issue?

Most likely, if the issue happens after a while, some buffers are being optimized away in release mode and fstorage hangs in the background without ever getting the complete event.

Best regards,

Simon

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Fri, 20 Mar 2026 12:39:34 GMT

Sorry, missed to see that there is a segger project there.

I tried to build it and I cannot build as there are files that are hardcoded filepaths that does not work with Mac that I have.

I need to ask for help from my colleague to run this on their Windows machine.

RE: Problem with fstorage and ble active in Release mode

Stebitt — Wed, 18 Mar 2026 13:07:49 GMT

Thanks for having a look at it.

We are not using IAR - we use "SEGGER Embedded Studio for ARM". You can download a free version from here:

SEGGER - The Embedded Experts - Downloads - Embedded Studio

The project can be started after installation by double-clicking this file:

...\nrf52_ble_fw-pool - FLO2_v03 - Robin\pca10040\s132\ses\ble_app_uart_pca10040_s132.emProject

Further details:
- we do not optimize the code in release mode
- address range we use is 0x007D000 - 0x007DFFF
- the last 128 bytes are not used (wrap around bevor) we only use the space to store 31x128 bytes

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Wed, 18 Mar 2026 06:49:44 GMT

Stephan,

I have review reviewed the project you attached. This seems an IAR project and I cannot see the main project file apart from the .eww file And the issue does not appear to be caused by the wrong fstorage backend being selected.

The behavior is more consistent with the flash operation not completing in the Release build. When that happens, the firmware remains in its idle wait path and appears stuck in sd_app_evt_wait(). This can still look fine in Debug mode because the different timing, lower optimization, and active logging often mask this type of issue. Also, I see that the application writes to a fixed flash address (0x0007D000). That address must be confirmed against the final linker layout. If it overlaps a reserved flash region, the result can be unstable and may only become visible in Release mode. There are some other threads that mention that nrf_sdh_soc.c could be optimized away if you do not make sure it is used right.

I cannot compile your project since it is IAR and I do not have a license for it.

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Tue, 17 Mar 2026 08:58:06 GMT

Hi Stephan, I am really sorry, this thread fell out of my visible queue. I will take a look at your project tomorrow. Sorry for the delays.

RE: Problem with fstorage and ble active in Release mode

Stebitt — Mon, 16 Mar 2026 08:48:29 GMT

Hi support - I wonder if you could proceed with testing our code regarding the issue we have.

Another attempt would be if you would provide me a code where BT communication and fstorage runs in compiled mode. Then we could add our application step by step to it.

I would like to emphasize that we really need your support in this matter.

RE: Problem with fstorage and ble active in Release mode

Stebitt — Thu, 12 Mar 2026 13:32:43 GMT

Hi - could you load my code to you platform and test it?

RE: Problem with fstorage and ble active in Release mode

Stebitt — Tue, 10 Mar 2026 09:58:10 GMT

It's called from the main. Here my code...

All the LED_ON / LED_OFF sequences are for debugging to see on an oscilloscope where the code goes through.

devzone.nordicsemi.com/.../nrf52_5F00_ble_5F00_fw_2D00_pool-_2D00_-FLO2_5F00_v03-_2D00_-nRF.zip

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Tue, 10 Mar 2026 08:26:09 GMT

Are you calling wait_while_fs_busy from main context or some other interrupt context?
I cannot do online meetings, if you can give me your code, I can do a quick test on my end to see why this happens only in released mode. Clearly there seems to be some timing issue.

RE: Problem with fstorage and ble active in Release mode

Stebitt — Tue, 10 Mar 2026 08:08:28 GMT

Shall I send you my code? Or could we do a online meeting to check? As said, when compiled for Debugg it runs. Could any other service block somehow the fstorage events?

Yes, I'm using nrf_fstorage_sd.c

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Tue, 10 Mar 2026 06:00:30 GMT

[quote user="Stebitt"] I tried also only the call of sd_app_evt_wait(); --> with same result - it hangs in this call[/quote]

sd_app_evt_wait should have worked. Can you please confirm that you are using nrf_fstorage_sd.c as the backend when you are initializing the fstorage? If yes, I would like to get a minimalistic project to replicate this issue on the DK on my end.

RE: Problem with fstorage and ble active in Release mode

Stebitt — Mon, 09 Mar 2026 13:24:19 GMT

Thanks for your replay. Will power_manage() comply with SD functionality?

could you please post the code of power_manage() - thanks

Remark to 'wait_while_fs_busy function is too complex' : I tried also only the call of sd_app_evt_wait(); --> with same result - it hangs in this call

In this case, the loop 'wait_while_fs_busy goes twice in sd_app_evt_wait(); within 30us and this repeats after 650us 6 times and then hangs again in sd_app_evt_wait();

RE: Problem with fstorage and ble active in Release mode

Susheel Nuguru — Mon, 09 Mar 2026 11:03:26 GMT

Hi Stephan,

Your wait_while_fs_busy function is too complex and unnecessary. We have already exposed the helper to check the status on nrf_storage . Your wait function can just use nrf_fstorage_is_busy

void wait_while_fs_busy(nrf_fstorage_t const * p_fstorage)
{
    /* While fstorage is busy, sleep and wait for an event. */
    while (nrf_fstorage_is_busy(p_fstorage))
    {
        power_manage();
    }
}