BUG: OpenOCD corrupts CPSR

Development Boards MicroMod
1

I have been ripping my hair out with some bizarre issues, and think I have narrowed it down:

It appears as though if I set a breakpoint at a location, stop there - then resume, CPSR will get corrupted.

I am seeing the following behavior:

Background:

I am always running in Supervisor mode

I am on an ARM7EJ-S (ARM7TDMI-S dirivitive)

  1. every time I halt or break, the CPSR is allways 0x400000d3

  2. If I change it (above) and step a single instruction, the CPSR again gets set to 0x400000d3, regardless of what happens.

  3. If I try to change the CPSR (manually) to modify a behavior (e.g. change Z flag to alter a following bne or beq) it does not change.

  4. I am currently executing as follows:

84:       4b4b            ldr     (r3, pc, #300)  (b4 <MAIN+0xb4>)
86:       681b            ldr     r3, (r3, #0)
88:       2b00            cmp     r3, #0
8a:       d002            beq     92 <Fault+0x52>

The value loaded (from memory) at 0x86 is always zero. This code will keep looping (regareless of branch at 0x8a).

If I break at 0x84 then RESUME, the branch is always taken.

If I break at 0x84 then STEP through the code, the branch (at 0x8a) is NOT taken - even though 0x92 r3 is zero, and the preceding comparison should have set the Z flag.

Inspecting CPSR in any case will (as described above) ALWAYS show the Z flag at being set.

Any ideas???

2

Hi,

Which version of the OpenOCD are you running? There used to be a problem with older versions of the OpenOCD, but I thougth these had been solved some time ago.

Could you run the OpenOCD with debugging enabled and send me the resulting logfile (run with “-d -l ”) to Dominic Rath gmx de.

Regards,

Dominic

3

I am running:

openocd_20060814-src.tar.gz

(This is the newst I found - Is there a newer one?)

If not, I’ll send debug.

Thanks!

-BKG

4

Sorry, I haven’t created any source releases in a long time, because they were rarely used, and almost immediately outdated. You should grab the latest version of code via SVN from either

svn://svn.berlios.de/openocd/trunk

or

http://svn.berlios.de/svnroot/repos/openocd/trunk

See http://openfacts.berlios.de/index-en.ph … le=OpenOCD for instructions on how to get and build the latest version, as well as usage instuctions.

Regards,

Dominic

5

Ahhh…much better!

Thanks!

-BKG

BTW: I don’t know if I have something hooked up funny or not, but I couldn’t even get a good JTAG ID with the Lattice settings you had:

Yours:

{ “lattice”, 0x40, 0x10, 0x04, 0x02, 0x01, 0x08, 0x00, 0x00, 0x18 }

Mine:

{ “lattice”, 0x40, 0x10, 0x04, 0x02, 0x01, 0x08, 0x08, 0x00, 0x18 }

The difference is on the output-invert.

Note that I don’t physically have this pin connect to my board - however, it is used internally by the Lattice part to turn on the buffers.

In this device - [I think] either DQ4 has to be low, or DQ5 has to be high, or the device won’t turn on its buffers.

6

Hi,

I don’t have a lattice cable myself. The cable definition was contributed by someone else. I’ll see if I can find a description of the cable. Thanks for noticing.

Regards,

Dominic

7

See:

ftp://download.intel.com/design/iio/dev … wnload.pdf