SparkFun Forums 

Where electronics enthusiasts find answers.

Open source ARM Debugger
By noice
#18610
I am having trouble running a program in RAM on an LPC2106 by means of OPenOCD's GDB interface - but only if the Flash is blank. What seems
to happen is that
- At reset, Philips boot loader takes over.
- My debugger stops the boot loader (Control-C to GDB server). I see the
registers PC usually 7FFFE24C, CPSR has N, I, F, and SVC mode.
Now, the Philips docs say that most of the boot code is in Thumb mode,
and the code at 7FFFE24C makes a lot more sense when disassembled as
Thumb code, but CPSR as reported by OpenOCD's GDB server says
ARM.
- My debugger sets CPSR to 0xD3 (ARM mode, interrupts disabled, SVC
mode)
- My debugger sets PC to 0x40000000, where my program starts
- My debugger sets a hardware breakpoint, says GO - and never hits the
breakpoint.
- Try again, but this time use single-step (GDB server 's' command).
Program stops with PC=0x40000002. Clearly, the processor is still in
Thumb mode, even though I set CPSR.
- Third try - don't even load my program. Apply power to target,
start OpenOCD, open a TELNET session to localhost 3333
Send $p19#da - get +$d3000080#bf (CPSR as above, little-endian byte
order)
Send +$pf#d6 - get +$4ce2ff7f#97 (PC as above: 7FFE2E24C)
Send +$s#73 - get +$T05#b9 (step, signal 5)
Send +$pf#d6 - get +$4ee2ff7f#99 (PC as above: 7FFE2E24E)

Any ideas as to what is going on - or more importantly, how to fix it?

Background:
I am writing a debugger (NoICE, at www.noicedebugger.com) and trying
to use OpenOCD as a GDB server. I also have support for RDI (tested
with H-JTAG and Segger's RDI DLL), and experimentally with OpenOCD's port 4444 command interface.

All three interfaces are operational, and neither RDI nor the
OpenOCD/4444 interface exhibits this problem. Both RDI and
OpenOCD/4444 show all the ARM shadow registers, while GDB only shows
the current set.

My assumption is that somehow CPSR isn't making it to the target. If
I run OpenOCD at debug level 3, I see a flurry of activity that claims
that it is (just before the program is run, rather than when I send the
register message). I have looked through the OpenOCD code, but I don't
know enough about ARM JTAG to really understand everything that is
going on.
By Dominic
#18623
Hey,

thanks for noticing this bug. To be able to debug the core, the OpenOCD switches to ARM state, and reads the CPSR after that. I'll add some code to report the correct setting of the T bit. The OpenOCD notices that the core is in Thumb state, and correctly reports this when you use the "poll" command.

The "armv4_5 core_state ['arm'|'thumb']" command allows you to change the mode in which execution is continued.

When using GDB, you'll have to use GDB's "monitor" command to have it send the command to the OpenOCD.

Regards,

Dominic
By Dominic
#18624
Revision 97 correctly sets the T bit in the CPSR.

Regards,

Dominic
By noice
#18669
With version 97, I now SEE the T-bit when I read CPSR.

But when I try to CLEAR it, and then run (or single-step) by program, the T-bit is still set and the first instruction in my program gets executed in the wrong mode.
By Dominic
#18680
The "armv4_5 core_state ['arm'|'thumb']" command allows you to change the mode in which execution is continued.
So far, this has been a design decision, but after adding correct reporting of the T-bit in the CPSR, adding a way to modify the bit via the CPSR could be added, too.

Regards,

Dominic
By noice
#18712
So far, this has been a design decision, but after adding correct reporting of the T-bit in the CPSR, adding a way to modify the bit via the CPSR could be added, too.
Not having this would seem to cause a problem even if you used GDB or Insight/GDB to drive OpenOCD: if the target happens to be in Thumb mode (most likely a Philips part with a bad vector checksum, or one that has a user program in Flash that is in Thumb mode when OpenOCD stops thew target), there is no way for GDB to force the ARM into ARM mode to begin executing a new program.

I realize that this is mostly the fault of Philips stupid reset scheme, but we don't have access to the source code for that! :)

Since I don't see this behavior when using the OpenOCD command-line interface, I presume that this design decision affects only the GDB server? Or is it just that the command-line interface's reset command has special code to force the target into ARM mode?
By mifi
#18717
Hello noice,

have you try the soft_reset_halt command too?

Inside gdb monitor soft_reset_halt, I belive that will set
the core to arm mode.

Regards,

Michael