[quote user="Michael S"]The mechanism is already in place. It's just a matter extracting the RTS lib, adding exit.c and placing the breakpoint or any other indicator of one's choosing.[/quote]Thanks, I didn't look in the RTS exit.c to see what abort did.
However, i think the following from the RTS assert.h:
#define assert(_expr) _NAMESPACE_PREFIX _assert((_expr) != 0, \ "Assertion failed, (" _STR(_expr) "), file " __FILE__ \ ", line " _STR(__LINE__) "\n") And assert.c:
/****************************************************************************/ /* _ASSERT() - Implements the assert macro. Checks the argument. Aborts */ /* with a message if not true. */ /****************************************************************************/ _CODE_ACCESS void _assert(int expr, const char *string) { if (!expr) _abort_msg(string); } /****************************************************************************/ /* _ABORT_MSG() - Write out a string and never return. Abort function for */ /* false assertions. */ /****************************************************************************/ #pragma FUNC_EXT_CALLED(_abort_msg) _CODE_ACCESS void _abort_msg(const char *string) { fprintf(stderr,"%s",string); fflush(stderr); /* Always a good idea to flush */ abort(); } is not optimal for a MSP430 device. The reason is that the string argument to the abort function and the fprintf code to output the string in _abort_msg could cause problems with lack of space on a MSP430 device. With the default RTS the output from fprintf (stderr) won't be visible unless the device is running in the debugger to capture the output, and so would the RTS assert.h be better to define the assert macro as a call to abort if the assertion fails?
You then just have to set a breakpoint on the abort function.
[to be honest, I haven't tried enabling asserts with driverlib to see how much the memory usage increases...]