[En-Nut-Discussion] Ethernut on TI's Cortex-M3 (Stellaris LM3S...)

[Ole Reinhardt]

Hi Philipp,

> Anyway, the problem I'm facing now is that the controller seems to hit 
> an unexpected interrupt or even an exception when running the example 
> code. The end result is that the LED does not blink, but according to 
> GDB the processor hangs in one of the endless loops found in 
> cortex_init.c, namely in IntDefaultHandler(). If I comment the loop 
> there, it looks like the CPU hits a BusFault, at least this is what 
> GDB/OpenOCD says.
> 
> Could anyone give me a hint on what to do now? I couldn't figure out how 
> to single-step through the program using GDB to find out where it enters 
> the handler and I don't really know the way through all of the Nut/OS 
> sources.

You use openocd? Great! So you can simply figure out where you are and
what caused the exception:




Let me explain it step by step.

What you need:

a) a buggy program
b) openocd
c) an assembler listing of your code

Prepare the last one:

arm-none-eabi-objdump -d buggy_program.elf > buggy_program.asm_dump

You will need it to find out the exact place of your exception


Next connect with openocd to your board and let your program run.

If your board crashed, call 


> halt
target state: halted
target halted due to debug-request, current mode: Handler BusFault
xPSR: 0x21000005 pc: 0x00000f60 msp: 0x10000928


The interesting part is the current stack pointer (msp) as the program
counter value of your exception was pushed on the stack before entering
the exception handler (a while(1) loop).

Read out the stack:

> mdw 0x10000928 8
0x10000928: 00000000 10001040 00000001 ffffffff 00000fbc 00002ec1
000005ee 21000000 



the "mdw 0x10000928 8" command reads out 16 words starting from address
0x10000928, where you should replace the 0x10000928 with the value of
your msp.


Find the 7.th value: 0x000005ee in this example. This is the address
where your exception occured.


Next look into our assembler listing (buggy_program.asm_dump)


     5de:       f04f 34ff       mov.w   r4, #4294967295
     5e2:       f44f 707a       mov.w   r0, #1000       ; 0x3e8
     5e6:       9410            str     r4, [sp, #64]   ; 0x40
     5e8:       f002 fdae       bl      3148 <NutSleep>
     5ec:       9b10            ldr     r3, [sp, #64]   ; 0x40
     5ee:       6818            ldr     r0, [r3, #0]
     5f0:       f002 fdaa       bl      3148 <NutSleep>
     5f4:       e7f5            b.n     5e2 <main+0x296>
     5f6:       bf00            nop

The above example shows you that the parameter to a NutSleep call caused
the error and that this is inside the main() function.

And here is the faulty code (sample):

        i = 0xFFFFFFFF;
        NutSleep(1000);
        NutSleep(*(uint32_t *)i);


Perhaps you want to know what the other values on the stack stay for?


address:       value:

msp            stacked r0 value 
msp + 0x04     stacked r1 value
msp + 0x08     stacked r2 value
msp + 0x0C     stacked r3 value
msp + 0x10     stacked r12 value
msp + 0x14     stacked lr value
msp + 0x18     stacked pc value
msp + 0x1C     stacked psr value






If you can not find the problem, please drop me a line. I also have an
LM2S9B96 development kit, so I could do some debugging here...

Bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - 
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97

Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280