Inconsistent crash handling NRF_EVT_FLASH_OPERATION_SUCCESS on first run after flash memory reset

[Jeremy]

During startup, I am encountering a new issue where the chip crashed out during boot. See screenshot for crash details:

"mesh_main_start()" is called from my main application code, and invoked after the Soft Device and BLE stack have been fully initialized. From there it calls "mesh_provisionee_start()" and it's all SDK calls after that. It looks like while generating uECC keys I'm running into a Soft Device event, and things are exploding as that event is handled.

What is unusual is that p_op->p_fs->evt_handler appears to be holding a value of 0x81febaf5 which falls outside the flash or ram ranges, so I think that may be the problem, but don't know where it's coming from or how to change it.

Some additional details:
- Only happens after a full memory reset ("nrfjprog -e") then reflashing the application
- If I reset/run multiple times, eventually it gets past this crash
- If it makes it past the crash, it provisions and functions correctly
- Once it makes it past the crash once, it never happens again

Thanks!
Jeremy

[Einar Thorsrud]

Hi Jeremy,

Yes, good catch! When you use Segger Embedded Studio and section variables (which are used by quite a few SDK modules, including fstorage which in turn is used by FDS), you need to have INITIALIZE_USER_SECTIONS defined. That is why you see this is defined in all Segger Embedded Studio example projects in the SDK.

[Jeremy]

That makes perfect sense. I started with a Mesh example and have combined it with the ability to establish BLE GATT connections (necessitating the peer manager) from the nRF5 SDK and missed that define when porting things over.

Thanks!