openOCD half working

Development Boards MicroMod
1

I am using the Olimex LPC2148 board with a wiggler/openOCD setup. Everything was working fine until several days ago.

What appears to be happening now is some of the binary I am trying to write is downloaded correctly while the later part of the binary is not transmitted correctly.

So when I look at my .bin file in a hex editor I see:

  • 0000 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

    0010 18 F0 9F E5 00 00 A0 E1 F0 FF 1F E5 14 F0 9F E5

    0020 40 00 00 00 AC 14 00 00 8C 14 00 00 AC 14 00 00

    0030 AC 14 00 00 4C 14 00 00 6C 14 00 00 00 00 00 00

    …

    1540 04 20 A0 E3 00 20 83 E5 00 A8 9D E8 0D C0 A0 E1

    1550 00 D8 2D E9 04 B0 4C E2 0E 32 A0 E3 7F 39 83 E2

    1560 84 30 83 E2 24 20 A0 E3 00 20 83 E5 D6 FF FF EB

    • But when I look at a memory dump of the mcu after programming I see:

  • 0000 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5 18 F0 9F E5

    0010 18 F0 9F E5 00 00 A0 E1 F0 FF 1F E5 14 F0 9F E5

    0020 40 00 00 00 AC 14 00 00 8C 14 00 00 AC 14 00 00

    0030 AC 14 00 00 4C 14 00 00 6C 14 00 00 00 00 00 00

    …

    1540 00 20 80 E0 00 20 80 E0 00 00 80 E0 00 00 00 E0

    1550 00 00 00 E0 00 20 00 E0 00 00 00 E0 00 00 00 E0

    • etc etc.

    I don’t get any errors when downloading just a message like this:

    >flash write 0 E:\eclipse\workspace\firmware\debug\firmware.bin 0
wrote 59888 byte from file E:\eclipse\workspace\firmware\debug\firmware.bin to flash bank 0 at offset 0x00000000 in 55s 377058us (1.056112 kb/s)
>

    Which seems ok?

    I assumed that the jtag_speed might have been too high so I set it to 10 (slowest I beleive) but then I read that it has no effect for wigglers anyway. So I threw away the parallel cable extension I was using and connected the wiggler (Olimex wiggler) directly to the PC port. But same problem.

    Does anyone have any ideas what went wrong?

    If it helps here is my openOCD config script in all its glory:

    #daemon configuration 
telnet_port 4444 
gdb_port 3333 

#interface 
interface parport 
parport_port 0x378 
parport_cable wiggler 
jtag_speed 10 

reset_config trst_and_srst 

jtag_device 4 0x1 0xf 0xe 
jtag_nsrst_delay 333
jtag_ntrst_delay 333 

#target configuration 
daemon_startup reset 
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4 
run_and_halt_time 0 30 
working_area 0 0x40000000 0x40000 nobackup 

#flash configuration 
flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 12000 calc_checksum
    2

    What’s changed since everything worked? I’m new to some of this stuff, but one of the things that really threw me for a loop at first was the memory mapping. It’s easy to remap certain sections of memory, which in the JTAG context mean you may read data out of “flash” that’s actually mapped to memory somewhere else. Is it possible that those higher addresses are mapped to somewhere else, and the JTAG interface is not actually reading out of flash because of a mode the arm is in as a result of something that’s happened in your program?

    I can’t offer more than that :oops: but I’m trying to be helpful!

    3

    Is it possible that those higher addresses are mapped to somewhere else, and the JTAG interface is not actually reading out of flash because of a mode the arm is in as a result of something that’s happened in your program?

    I had never thought of that. But I am pretty sure the wrong data is being loaded because:

    • If I manually set the program counter to 0x0 then the program starts up and gets some instructions done (at least until it enters a sector with invalid data!).

    • Also some of the functions appear to reside in the bad sectors, so I don’t think it is being remapped - maybe incorrectly remapped?

    I can also see something going in with an oscilliscope on TDO/TDI. But then when I push reset it just jumps to some empty memory.

    What’s changed since everything worked?

    I wish I knew… Maybe the wind?

    4

    Where is the disconnect? (ie: where does your data go bad?) Does it occur at an actual sector boundary? If so, can you take steps to be sure that those sectors are getting erased properly? (ie: erase, and then read to check for 0xff before writing again)

    5

    Can you post the full sequence of commands you use to halt and program the target.

    /Magnus

    6

    Thanks for your input guys.

    I changed the “flash erase 0 0 0” command to “flash erase 0 0 17” (LPC2148 has 17 flash sectors), then everything worked fine. I think what happened was my code size increased so it was falling over the boundary of one of the sectors that wasn’t erased properly (Thanks Ryan!).

    I don’t know how to set this topic as solved?