Best approach to diagnose the cause of System Panic Reset

I am trying to work back from hard evidence now obtained that Xenons operating in a Mesh network (no Cloud connection) are resetting with cause RESET_REASON_PANIC. There are 7 endnodes connected to a Xenon based ethernet gateway. The reset reason is being read in setup() and published via a mesh pub to the gateway. The resets are occurring no matter how many endnodes are active. The resets are happening with a high level of LiPo battery charge (3.9-4.1V). The endnodes are connected to a AMG8833 Thermal Image camera and a DS3231 RTC both over I2C. There is a complex cycle of sleeping and sensor reading driven by activity. The endnodes were reporting free memory level - this has been removed as it did not appear there was a memory leak i.e. it was stable for long periods. I have checked the stack size and that doesn’t appear to be a cause. I can’t see any particular pattern in the resets and I am now looking for an advice about how to instrument the application to catch more information to help me track this issue down.

Could it be caused by something going wrong w/ the I2C bus ?

Can you test a Xenon that simulates a similar Sleep Cycle but comment out the Code for the Camera ?
Then try the same for the RTC ?

Thanks - that could be an approach. I should have said before that the same base code with RTC and another sensor can run for ever. So it is highly likely that the AMG8833 I2C is the problem.

I have had success in the past by running the debugger in Workbench and setting a breakpoint in the panic handler. If/when the breakpoint triggers you should be able to see the stacktrace which will indicate the offending line which caused the panic.

2 Likes

@joel Another good idea - thanks. I have run the Serial Log Handler and monitored that with no success - maybe something with the USB cable in that stops the problem? I will give the debugger a chance.