How can I debug an unexpected reset on the EM250 platform?
A cause of RESET_ASSERT means that some illegal condition (checked by an assert() statement) was violated in the code. In most cases (depending on hardware setup), this reset type will be accompanied by a printout of the filename and line number where the assert occurred, outputted to the debug channel via SIF (for viewing by InSight Desktop during a capture) or the UART (if used). This can be used to determine which statement of code was in error. Most often this information will reference a file within the EmberZNet stack itself. As these file names and line numbers can change with the evolution of the code, it's not possible to provide a set list of all possible asserts that could be triggered, so if you detect a RESET_ASSERT condition, you should consult Ember Support to inquire about the meaning of a specific assert failure. (Note that these failures most commonly occur in the packet-buffer.c module, indicating misuse of the APIs from stack/include/packet-buffer.h.)
One thing you can do to diagnose these unexpected resets is use the PC Diagnostics functions in the HAL. The /hal/micro/xap2b/em250/diagnostic.h file documents the various calls you’d use to help track the last-known program counter after reboot:
int16u halGetPCDiagnostics( void ); void halStartPCiagnostics( void ); void halStopPCDiagnostics( void );
Some guidelines: halGetPCDiagnostics() should be called before halInit() to grab the last-saved PC value from previous runtime. halStartPCDiagnostics() should be called after halInit() to initialize the session. INTERRUPTS_ON() must happen after halInit() as well.
You can then relate the PC to the program flow using the list file output from your build (final <program-name>.LST file created during the build), which shows the addresses of the code.
Most often the PC value or location of an assert() failure will relate to code within the stack's own packet-buffer.c module, since this is the module that handles EmberMessageBuffer allocations and manipulation, which is generally the area where the application deals with arrays and copies them to/from packet buffers. However, as the packet buffer code is quite stable and well-tested, it is unlikely that the fault relies in the packet-buffer module itself. (In all cases so far with the EmberZNet stack, we have yet to discover an instance where the packet buffer module was the cause of the crash; it has always been caused by either a RAM manipulation that corrupted the EmberMessageBuffer structure data or an invalid parameter being passed to an API call of packet-buffer.h.)
What often happens to cause the crash is that the application may have a stray pointer reference or other kind of memory overwrite situation that causes certain portions of RAM to be written to zero or other random values, corrupting the call stack or other program flow data and causing the code to execute an illegal instruction.
Developers debugging these sorts of issues should examine places where the code directly manipulates pointers or arrays, as these are likely the areas of risk for this kind of thing.
In terms of tracking down the location more precisely, the code generated by "xIDE for EM250" 1.x doesn't really have the ability to obtain the call stack at runtime; however, you may be able to step through the code one procedure at a time until you narrow down the section where the crash is occurring. Another possibility is to update the system to EmberZNet 3.3.x (or later), which uses a rewritten compiler, version 2.x of the xIDE for EM250 package; that newer compiler at least has the ability, via the xIDE debugger, to view the call stack so that, if the debugger captures the crash, you can see the call stack leading there (rather than having to step through a piece at a time until you hit it).
Hopefully, with these methods and some investigation, you will be able to track down the source of the memory issue causing the crash.
- Login to post comments
