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]

And now it's working ... but I'd still like to understand what was broken if anyone can shed any light.

I flashed an example project to see if I couldn't dig in a bit more, and when switching back to my application I appear to have no issues at all. Inserting a breakpoint in "event_send" where things were blowing up before and p_op->p_fs->evt_handler is now set to 0x00000000 which skips all the logic in that function and the handler call at the end that was sending me off to never-never-land.

This only fires off on the first run after a complete memory wipe (nrfjprog -e), so the triggering behavior hasn't changed, just the value held by p_op->p_fs->evt_handler is now NULL which avoids my problem.