Hello Kristoffer,

As a quick reply, definitely ack on the problem statement. I can say
more, I'm patiently waiting for a paradise times when on CPU exception,
assert, etc., we'll be ending up in debugger, point to the instruction
where the problem happened (or it can be seen in backtrace). (To be
exact, I'm talking about running in QEMU first of all, I actually
don't remember how that works on real hw.)

As for specific implementation, perhaps more knowledgeable people can
comment. I would just point that an obvious override point is
__ASSERT_POST macro itself. I.e. instead of defining it
unconditionally, we can have #ifdef around it, and let a user override
it before inclusion of Zephyr headers. That's the simplest, but
perhaps not the most scalable solution.


On Fri, 09 Nov 2018 01:39:34 -0800
kristoffer.skoien@... wrote:

Current implementation:

The __ASSERT macro is extensively used in the Zephyr code base and in
application code for debugging during development.

In case of an ASSERT, the code jumps to __ASSERT_POST which spins the
given thread in a while(1).

 

Issue:

During development and debugging, simply looping the thread will mask
that the ASSERT has triggered. The only feedback the user gets of an
assert is a printout.

This can be missed if e.g.:

- The RTT or Serial debug interface is down or unused

- There is too much logging so that the “ASSERTION FAIL” can be missed

 

Proposed solution:

In __ASSERT_POST provide a function call that will end up a user
definable error handler. E.g. _SysFatalErrorHandler()

 

This will let the developer set given SOC pins in case of an ASSERT,
ask for a specific LED pattern to be set or print further debug
messages.

 

Feedback is appreciated.

 

Kind regards

Kristoffer

--
Best Regards,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog