Given this error handler function...
and this logging from it with the Segger attached...
how do I debug this?
I presume the info passed in is bogus and just points to some random part of memory.
75936 is 0x128A0 and that's in the soft device.
My code is not doing anything in particular when it hits this. It tends to happen out of the blue. The nRF52832 is not in a BLE connection at the time but it is advertising. It's listening to a GPS module over SPI, running a bunch of timers, and that's about it.
Also, NRF_LOG_FINAL_FLUSH() doesn't appear to work, because I frequently see this while the Segger is attached, testing on the desk, but I never see it logged to my in-memory log in field testing.
[Edit]
Here are three log "files" to demonstrate my logging problem.
This one is a Segger RTT log taken from desk testing with the debugger attached. I get the error logging for the assert that stops execution just fine.
This one is taken from my in-RAM log generated during field testing, but read back once I'm back at the desk with a tiny pynrfjprog Python script that just converts a RAM region to ASCII. I'm not worried about the PANIC at the end - that's just the panic function in my log backend being called as the Nordic goes into sys off. This is an example of a "good" in-RAM log for me - I can see everything up to the last sys off or assert.
And this one is taken from my in-RAM log again, same as the second one, but this one is "bad" because there's no sys off at the end and no assert. I have some normal debug logging from my GPS driver and then a lot of memory that looks like it never got zero'ed out when the in-RAM log was initialised. I can't tell what the software died from here. I suspect an error, because the device isn't doing anything, but I can't tell what's happened.
Note that my in-RAM log is a circular buffer so it'll wrap around to the beginning, which is why this one doesn't start with the same init stuff.
[Edit]
Here's my error handling code.
The build I'm testing with is a BUILD_FIELD_TEST.