I have build OpenOCD from the Git repository for the TI ICDI support. It appears that it is working for the most part, but I am getting a lot instruction errors when single instruction stepping through code. I know the code is good. I also have access to a JLink and using the Segger GDB server (with the same arm-none-eabi-gdb client) I don’t see the instruction errors.
It was recommended that I add “set mem inaccessible-by-default off” to my gdb init but that doesn’t seem to have fixed the issue either.
One thing I did notice is that if I am debugging a TI Stellaris board that has one of the older FT2232 JTAG interfaces, when I connect using OpenOCD I get a lot more output, specifically it auto-detects what device is being accessed.:
Info : only one transport option; autoselect 'jtag'
adapter speed: 500 kHz
Info : device: 4 "2232C"
Info : deviceID: 67353817
Info : SerialNumber: 082106FCA
Info : Description: Stellaris Evaluation Board A
Info : clock speed 500 kHz
Info : JTAG tap: lm3s.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3)
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3332
However, when I am debugging on a new board with one of the TI ICDI interfaces I only get:
adapter speed: 1000 kHz
Info : clock speed 1000 kHz
Info : ICDI Firmware version: 8790
Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection from 3332
Here are the debug output logs from OpenOCD. “debug_good.log” was when I was debugging and getting NO instruction errors. The “debug_bad.log” is when I WAS getting instruction errors. They are not from the same target or with the same running program. The one of interest is really “debug_bad.log” I only included “debug_good.log” because I was using it for comparison sake.
And to that point, I noticed that “debug_good.log” reference the source “cortex_m3.c” a lot whereas in “debug_bad.log” the source “hal_target.c” was referenced a lot when reading back registers and the like. Early in the “debug_bad.log” I do see that an Cortex M4F core is correctly detected. One of the key differences between “debug_good.log” and “debug_bad.log” is that they were recorded while debugging a Cortex-M3 and a Cortex-M4F respectively, I just assumed that given how similar they are that OpenOCD would essentially treat the M4 as an M3. Maybe I am wrong?
So I did what you suggested and tried to run “compare-sections” from GDB, of course I needed to provide in the ELF file first. Once I did that, it started to work fine.
In the past I have been able to use ‘arm-none-eabi-gdb’ for remote debugging without having to give it an ELF, I was just limited to only debugging at the assembly level.
cmeyer:
In the past I have been able to use ‘arm-none-eabi-gdb’ for remote debugging without having to give it an ELF, I was just limited to only debugging at the assembly level.
I am not sure but it may be the case for the older arm7/9 targets, but not for targets that use thumb2 instructions.
Really? Because the above “debug_good.log” where I wasn’t getting the instruction errors I was debugging a Cortex-M3 without providing a symbol file.
Typically I do use a symbol file, but sometimes I get a board I need to debug where I don’t have access to the symbol file and I am not permitted to reflash it.