Hi.
My SAM7X-EK tools (KEIL-uV4 with ULINK2 and SAM7X-EK board) doesn't work properly anymore: I LOAD my new software via Keil/ULINK2 OK ("Erase Done", "Programming Done", "Verify OK"). But when I enter Debug Session (the "d-icon" from Keil uV4), it seems like the CPU is automatically started (or maybe not started at all?). Because, immediately after entering Debug Session: The RST-icon (RESET) is shaded, the Run(F5) icon is shaded, but the STOP-icon (red circle w/white "X") is highlighted...
I then push the STOP-icon and set a breakpoint at "main()". I then push RST-icon(RESET) and Run(F5), but the code never enters/breaks (stops at) main().
Does anyone have a clue what's wrong with my development tools? Could it be a HW-failure on the SAM7X-EK board or within the ULIK2 (or simply a setting)? Does anyone have the same experience?
I really hope someone could assist me on how to proceed with this problem.
Best regards Terje Bohler
After more investigations I now see what's happening: After LOADing the program and entering Debug Session (the red "d-icon"), I took a look at the Registers ("View" + "Registers Windows"). What I see is that R15(PC) is set to 0x00000000. So when I Run(F5) my program (either manually by pushing the Run(F5), or automatically if the "Run from main()" is selected in the Debug-option for my Target system) it starts executing from PC=0 (an not 0x100000 where my program is).
My solution/cure: After entering Debug Session: 1) Stop the program if it runs (by pushing the red STOP-icon) 2) Modify the contents of the R15(PC) register to 0x100000 3) Push Run(F5) and the program start OK. NOTE: DO not push RST-icon before Run(F5) because the R15(PC) will be zeroed again ...
But, I guess this strange behavior is due to some wrong Keil uV4 configuration/settings ? I would really appreciate further comments to this issue.
Best Regards Terje Bohler
I'll make these comments without knowing about your specific processor.
But the processor starts from the address where it expects the reset vector to be. Normally address zero - some processors might have programmable fuses or might sample some processor pins on boot to pick up an alternative start address.
Processors that can't pick up alternative start addresses using fuses etc would normally need that a boot loader picking up from address zero and then have the boot loader jump to the real start address of the application.
When doing debug builds for running in RAM, you normally use a debugger script that sets the PC to the start address of the program image in RAM before the debug session is started. This works great when the goal is to have faster download times and to avoid wearing out internal flash - but isn't a usable solution for live use.