Problems running program in RAM on LPC2106 if Flash is blank

Development Boards MicroMod
1

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.

2

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

3

Revision 97 correctly sets the T bit in the CPSR.

Regards,

Dominic

4

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.

5

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

6

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! :slight_smile:

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?

7

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