SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By cmeyer
#154531
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 <UNDEFINED> 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 <UNDEFINED> 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.:
Code: Select all
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:
Code: Select all
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
Any ideas?
User avatar
By ntfreak
#154534
The difference in log is due to the driver used by the icdi - it would error if it failed to detect a device.

I can only suggest you enable debug log and post here, when connected as a gdb server OpenOCD will only return the info requested by gdb.
as a test what happens when you issue a compare-sections cmd in gdb ?

Cheers
Spen
#154536
Here are the debug output logs from OpenOCD. "debug_good.log" was when I was debugging and getting NO <UNDEFINED> instruction errors. The "debug_bad.log" is when I WAS getting <UNDEFINED> 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?
You do not have the required permissions to view the files attached to this post.
By cmeyer
#154537
Huh...

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.
User avatar
By ntfreak
#154538
Both these logs look ok to me and OpenOCD is doing what it has been asked.

OpenOCD does treat m3 and m4 the same, the reason you are seeing different logs has to do with the adapter used.
The stlink and new icdi use a hla target (high level adapter) as they do not support low level cmds that the other adapters do.

gdb will only show undefined instruction if it does not understand the program memory returned by OpenOCD.
Does a gdb cmd compare-sections work ?

Cheers
Spen
User avatar
By ntfreak
#154539
cmeyer wrote: 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.

Spen
By cmeyer
#154540
Really? Because the above "debug_good.log" where I wasn't getting the <UNDEFINED> 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.