So close yet so far...
Hardware: TI AM1707 EVM - ARM926EJ-S microprocessor (not MCU, so not officially supported in the device database)
Debugger: Segger J-Link
Application: GNU compiler toolchain + working LED code
When loaded with J-Link + GDB, the LEDs light up correctly
When loaded by J-Link + uVision, the debugger SEEMS to give me access to the board, but the application doesn't run correctly (starts near 0xFFFF0000, which is on-chip local ram)...
Am I missing something totally basic here? Any help would be greatly appreciated!!
-Jonathan
A bit of progress, viewing the disassembly:
When the debugger first loads, PC=0xFFFF0000.
Next, force program counter to my application's entry address (0xC108010C) - opcodes here are random and incorrect, regardless of "Load Application at Startup" - if the Command "LOAD D:\led.elf" is issued, opcodes become all zero - "arm-none-eabi-objcopy -O ihex led.elf led.hex" + "LOAD D:\led.hex": nonzero opcodes, but still incorrect?
So at least the problem is narrowed down to uVision not being able to load the application correctly into memory - probably an incorrect application output format? But not sure how to fix...
Project Options > Output > Generate Hex File Project Options > Debug > Load Application at Startup
hex file is identical to what i generate manually via arm-none-eabi-objcopy -O ihex
through the magic of uVision, however, now the opcodes seem to be loaded at the correct addresses in memory
PC still starts incorrectly at 0xFFFF0000 (start of ARM local RAM)
if i force PC to 0xC1080000 (new forced address of my application entry point), code seems to run along until it's time to jump to my C startup function, and then it jumps inexplicably to some address in the middle of nowhere (0x42E7FF9C, which for my SoC is not even on the memory map)
Correction, led.hex has to be manually loaded using "LOAD build\led.hex"
i don't know what's going on now, but then again i never did..
ok, previously opcodes were corrupted due to my confused testing
the command "load build\led.hex" had to be issued manually and then set PC to 0xc1080000. maybe this can be done in the initialization script? in any case my blinky example is up and running now
is this really the normal workflow for this $5000 compiler?? gdb is starting to look more and more bang for the buck
NO, confound it, it is not. I may very well be 0xFFFF0000 (start of ACMEC3KLQ local RAM)
memory mapping is chip dependent
Erik
is this really the normal workflow for this $5000 compiler??
no, it is not, I, and all I know, do not have any such problems.
Bring up the IDE, load the project [change device} [change debugger settings] and GO
had to be issued manually and then set PC to 0xc1080000 sounds as if you have selected the wrong device.
View all questions in Keil forum