[En-Nut-Discussion] newlib itoa() and RAM funny problem

[Ulrich Prinz]

Thanks for the instructions on debugging. But I am pretty aware of how to
fire up the GDB.

I just counted one and one and thought that using a function that worked or
not choosing it cannot decide if the program hard-faults.

I did not place a bug into my software. I just decided to write a program
not using itoa() anymore.

So we are at compiler, linker, newlib level.

I modified yagarto script to work with Ubuntu 12.04 and got a compiler
after some zlib mess.
Tests will start on Monday at last.

Best regards
Ulrich
Am 16.11.2012 16:33 schrieb "Philipp Burch" <phip at hb9etc.ch>:

> Hi all,
>
> no need to search for the instructions, here are they (still great, thanks
> Ole!):
>
> On 10/15/2012 Ole Reinhardt wrote:
>
>> 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
>>
>>
> Happy debugging,
> Philipp
> ______________________________**_________________
> http://lists.egnite.de/**mailman/listinfo/en-nut-**discussion<http://lists.egnite.de/mailman/listinfo/en-nut-discussion>
>