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

[Jeremy]

Working backwards, the only thing that invokes calls that could generate this event that I'm using is the Peer Manager, and commenting out "peer_manager_init()" from my initialization code prevents this from happening during boot. I believe I still need the Peer Manager module to support scanning and connecting to BLE GATT devices, but this appears to be the root of the issue if that helps.