Debugger crashing! ARMDIDebugHandler .data on a 4 byte boundary?
I have been experiencing a strange issue where the debugging is crashing when I try to make the first step after the debugger launches. The debugger pauses for a while, then seems to timeout and show “Debug Handler has not started” on the bottom of the CrossStudio window and stops debugging.
I am running a pretty simple application that just has a long “for” loop, turns an LED on, has another long “for” loop, turns the LED off and repeats. I've tried the same thing on a more complicated project with the same result. It crashes on the first line of code in the main function (stmfd sp!, {r11, lr}). (The stack pointer seems to be setup correctly). I can put a break point in the “reset_handler” function in the “AT91SAM9_Startup.s” file, and step fine as far as the main function.
This only seems to happen when the .data section of the “ARM Debug/ARMDIDebugHandler.o” is not on a 4 byte boundary. I have moved the .data section to be the last section in the memory map. In the map file I see this:
…
.data 0x70007ee0 0x2 ARM Debug/ATestFile.o
0x70007ee0 testShort1
.data 0x70007ee2 0xc8 ARM Debug/ARMDIDebugHandler.o
.data 0x70007faa 0x0 ARM Debug/BTestFile.o
…
If I remove my test variable from before the ARMDIDebugHandler so that it’s now on a 4 byte boundary, and add a variable after the ARMDIDebugHandler (so that everything to follow is unaffected), the code runs fine!
…
.data 0x70007ee0 0x0 ARM Debug/ATestFile.o
.data 0x70007ee0 0xc8 ARM Debug/ARMDIDebugHandler.o
.data 0x70007fa8 0x2 ARM Debug/BTestFile.o
0x70007fa8 testshort2
…
Has anyone else experienced something similar to this, or understand why this is happening? Am I on the right track with the “ARMDIDebugHandler.o” data alignment, or am I just chasing shadows? Does anyone know of an easy way to enforce that the data variables from this file start on a 4 byte boundary?
Please sign in to leave a comment.
Comments
0 comments