rtems_error(RTEMS_ERROR_PANIC, (...)) and rtems_error(RTEMS_ERROR_ABORT, (...)) both reset?

[Nick Withers]

On Mon, 2013-08-05 at 09:49 +0200, Sebastian Huber wrote:
> Hello,
> 
> On 2013-08-05 08:11, Nick Withers wrote:
> > Hi there!
> >
> > It seems that rtems_error(RTEMS_ERROR_PANIC, (...)) and
> > rtems_error(RTEMS_ERROR_ABORT, (...)) both cause resets on the MVME3100
> > board I'm using with RTEMS Git HEAD (updated today).
> >
> > I believe this differs from 4.10 but have run into some troubles on my
> > side trying to verify this.
> >
> > Is the behaviour I'm seeing intentional? I was under the impression
> > (e.g., from
> > http://www.rtems.org/onlinedocs/doxygen/cpukit/html/error_8h.html#details ) that the RTEMS_ERROR_PANIC case should leave the system up but halted...?
> >
> 
> yes, the system termination handling changed from RTEMS 4.10.  Now every 
> terminating execution path (unexpected exception, exit(), etc.) should end up 
> in _Internal_error_Occurred() which invokes the fatal error extensions.
> 
> http://www.rtems.org/wiki/index.php/4.11_Release_Notes

Thanks Sebastian!

Don't suppose this could be explicitly mentioned in those Release Notes,
could it? My reading of the pertinent parts just told me that internal
implementation details had changed (for instance, it's noted under "API
Improvements"), but not that the API has.

I can probably do so myself, if you'd like?

> http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__ScoreIntErr.html
> 
> The application can provide an initial extension to do application specific 
> termination handling.
> 
> The default provided by the BSP is to call bsp_reset().
-- 
Nick Withers

Embedded Systems Programmer
Room 2.26, Building 57
Department of Nuclear Physics
Research School of Physics and Engineering
The Australian National University (CRICOS: 00120C)

eMail: nick.withers at anu.edu.au
Phone: +61 2 6125 2091
Mobile: +61 414 397 446