NRF52 code stuck and restarted

[Waqas Qammar]

Hello guys.

I am using a board based on the NRF52840 device. We run a code that we developed earlier and it was not well coded but working. it involves the interfacing of three to 4 different sensors interfaced based on SPI and I2c. All these sensors generated interrupts, a flag is set in gpiote handler and in the main loop the data is read and stored. The stored 4KB data is sent via BLE every second using a number of packets. The code was based on the ble_app_uart example and the SDK is 17.02

Now, when I started cleaning up and started to confined the code of each sensor in a separate .c file. Initially, it worked fine for 10 minutes to half an hour, and then suddenly we saw that BLE transmission stops. when I pause the code in the debug mode it was at 0x00025F40. I think it is softdevice address but why it is stuck I don't know the reason.

Then I tried, I take the previous stable code and just copy the exact same sensor-related code in another file with two functions so I can call it in main and loop. no change at all. Now the code runs for 10mis to 30mins and then it comes to the first line of the main and stops. I check the call stack and the address is 272B2. That is strange because there should not be any command that ends with B2. it should be B4 or B0.

I am really frustrated at this point that a piece of code running in the main.c stable and we did the test for 5 hours, but during the cleanup, and it if we copy it to another file, it just broke after half an hour with no clue of what is the reason for that behavior.

Surely I can't show the code because it's part of the early production stage. but would appreciate any help that I can use for debugging.

I checked the memory leakage as best as I can. the memory is static and I am not going beyond its length in any case.

[Einar Thorsrud]

Hi,

Which exact SoftDevice version are you using?

The screenshot here shows what I would expect to if pausing after jumping to main, as normally happens automatically when you debug. So this screenshot does not seem to indicate any issue (except if the reset was not expected?). The instruction address which is not a multiple of 4 looks a bit odd, but it likely just a Thumb instruction (in the SoftDevice in this case), which are 16 bits.

As this looks like a reset, I would start by checking the RESETREAS to verify that it was a reset, and what the reset reason was. That should give a pointer to where to look next.