Bugs or Benefits ?

Unhandled interrupt 0000000X !

Printed over and over again in the terminal when you power up the board.

One possible reason is that the Flash memory contained other code when you loaded Mecrisp-Stellaris, and the flash method you used ‘automatically’ erased enough Flash memory for Mecrisp-Stellaris, but didn’t erase the previous code area. What needs to be done is a block erase of ALL FLASH before loading Mecrisp-Stellaris.

Old Words Remain After Upgrading Mecrisp-Stellaris!

Q1) I’ve just flashed a new version of Mecrisp-Stellaris and my old Words are still there !

Is this a bug or a feature ? Actually it has nothing to do with Mecrisp-Stellaris and the answer is exactly the same as in Q1) above. If you want to completely remove your old Words you need to do a block erase of the board Flash memory.

Unhandled interrupt 00000003

My new Word results in endless “Unhandled interrupt 00000003” messages and needs hard a reset to stop it.

Interrupt 00000003 is a ‘catch all’ for any EXCEPTIONS that have been raised but not handled. A likely cause is your program caused the Program Counter to stray somewhere it’s not supposed to.

How can I stop that “Unhandled Interrupt 00000003 !” message ?

If I for example read beyond RAM from $20008000 I would expect that it would report once and then carry on as normal or at least reset afterwards. At present I have to reset the mcu after it has scrolled up thousands of lines beyond the top of the scrollback of the terminal.

Solution

You can change the way fault interrupts are handled by hooking “irq-fault” which points to “unhandled” for default.

For example, load the calltrace utility (mecrisp-stellaris-2.5.4/common/calltrace.txt) and install its handler:

' ct-irq irq-fault !   / trap the 'catch all intrerrupt', stop endless scrolling until pwr reset

HOWTO stop the endless “Unhandled Interrupt 00000003 !” message and reset the mcu

Inside the calltrace.txt file there is a definition named “calltrace-handler”, comment out “begin again Trap execution” and replace it with “reset” as shown below.

: calltrace-handler ( -- ) \ Try your very best to help tracing unhandled interrupt causes...
  cr cr
  unhandled
  cr
  h.s
  cr
  ." Calltrace:" calltrace
  \ begin again          \ Trap execution
  reset
;

A few notes and example of the calltrace tool

You can trap any interrupt by writing a ( – ) definition, tick it and place its address into any of the irq-* pointer variables. Forth will handle all housekeeping necessary for interrupt entry and return. The interrupts which do not have individual hooks launch through “irq-common”. Inside of your collection handler you can do something like “ipsr case”.

Fault interrupts are always active, for others, you have “eint” “dint” and “eint?” at your fingertips.

One more note: If you compile a definition called “init” into flash, it will be executed automatically on boot.

compiletoflash
load calltrace.txt
: init ( -- ) ['] ct-irq irq-fault ! ;  / trap the 'catch all intrerrupt', stop endless scrolling until pwr reset

This will install the calltrace utility permanently.

Testing

Make a ‘crash’ word and compile it to flash

: crashme ( -- raise exception ) 2000000000 @ ;

Now run it:

crashme

Unhandled Interrupt 00000003 !

Stack: [0 ] 0000002A
Calltrace:
00000000 0000B37B  calltrace-handler
00000001 FFFFFFF9
00000002 77359400
00000003 00001820  h@
00000004 200011D6  crashme
00000005 00000020
00000006 FFFFFFFF
00000007 0000462F  interpret
00000008 200011E2  crashme
00000009 01000000  ~~~project~~~
0000000A 000046A5  quit
Mecrisp-Stellaris RA 2.5.4 with M0 core for STM32F051 by Matthias Koch

When run crashme you will get a status like above and the offending Word will be listed along with the address in the dictionary, but you don’t need to decode it as below i.e.

' crashme hex. 200011D6  ok.

Why does “crashme” raise a exception ? because the memory area of 2000000000 is forbidden, it’s not in flash or ram, in fact it doesn’t exist at all.