- Tue Jan 19, 2021 2:42 pm
#222521
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.
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.