Hello,
I am trying to debug a program on Apollo 3 Blue MCU (on the Redboard Artemis ATP board) over SWD, using Keil uVision 5 with a ULINK2 debugger. I started with the example blinky project provided by Keil for the Apollo3 EVB, and modified the code to blink the Redboard built-in LED.
Problem: I am able to enter debugging mode, but cannot step through the code.
Details: After reset, the PC is set to 0xC0624AD2 (reserved memory), and numerous "Cannot access Memory" errors are displayed in the command window for addresses starting there. After the first (and all subsequent) debugging steps, the PC is set to 0x00000000, more"Cannot access Memory" errors are displayed for addresses from 0x00000008 to 0x0000000C, and a hard fault is generated. The thumb bit in xPSR is 0 from reset, probably because the first address loaded into PC, 0xC0624AD2, is even; possibly this could be causing the problems. But this value is indeed what is stored at 0x00000004, where the reset vector should be; yet the startup_apollo3.s file with the vector table is included and the .map file shows the reset handler at 0x0000c101, so I do not understand why the correct reset handler address is not stored at 0x00000004 to be loaded into the PC. If I manually set the thumb bit to 1 and set the PC to the reset handler address, I can step through the reset handler (only in the disassembly window), but it never jumps to main(), instead getting stuck in a loop after the reset handler.
Are there any known problems using Apollo3 or Redboard Artemis ATP with ULINK2 or Keil MDK that could cause this behavior, or other ideas as to what the problem could be? I'd appreciate any suggestions on the matter.
Thank you for your reply. I posted on the Ambiq forum also, but have not heard back.
Here is a link to Apollo3 Blue: https://ambiq.com/apollo3-blue/
Yes, it's including debug info. At this point I wouldn't have expected the problem is with the debug settings, but maybe I am missing something. Here are the Options for Target settings I am currently using.
Lydia King said:I posted on the Ambiq forum also
When cross-posting the same question in multiple forums, always give links - so people don't waste time repeating what's already been said.
Nothing leaps out from those settings.
Do Ambiq provide a ready-to-go example to try?
This question is also on the Ambiq forum and SparkFun forum.
Some example uVision projects are included in AmbiqSuiteSDK; when I tried debugging one it gave the same results (PC started at 0xC0624AD2, then remained stuck at 0x00000000 after stepping).
The .map file from the blinky project shows the vector table starts at 0x0000C000, where the flash programming algorithm defines IROM to start. I wonder if somehow the flash programming algorithm needs to be changed to start at 0x00000000, or the program could be made to start at 0x0000C000? The R/O Base in Linker settings was set to 0x00000000 so I thought maybe changing it to 0x0000C000 would fix that, but the results were the same.