Olimex LPC2148 + OpenOCD Flash Problem

Development Boards MicroMod
1

I’m hoping that someone can help here, I have spent 3 days now trying to get an Olimex (IAR) LPC2148 + Olimex Tiny JTAG system to work.

Most of the problems that I have experienced have been solved by browsing forums, but one puzzling one remails.

I am using OpenOCD, with a .cfg file tailored to work with the Tiny JTAG device.

The cfg file looks like this:

#daemon configuration
telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG TINY A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0004
jtag_speed 3

#use combined on interfaces or targets that can't set TRST/SRST separately
reset_config trst_and_srst separate

#jtag scan chain
jtag_device 4 0x1 0xf 0xe

#target configuration
daemon_startup reset

target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30

target_script 0 reset oocd_flash_lpc2148.script
working_area 0 0x40000000 0x40000 nobackup

flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 0 12000 calc_checksum

Startup of OpenOCD is fine, with no error messages:

H:\ArmDevelopment\lpc2148>openocd-ftd2xx -f .\lpc2xxx_armusbocd_tiny.cfg
Info:    openocd.c:93 main(): Open On-Chip Debugger (2007-09-05 09:00 CEST)

A telnet session is able to communicate with OpenOCD, so no problem there.

So the problem is that the flash erase/write commands don’t appear to work, but no error messages are presented. Here is an example of a session:

> mdh 0x0 100
0x00000000: 4034 e59f 5002 e3a0 5000 e584 5003 e3a0
0x00000010: 5004 e584 201c e59f 3000 e3a0 0093 e102
0x00000020: 2028 e282 1093 e102 3007 e3c0 3028 e502
0x00000030: f004 e51f d1c0 7fff c014 e002 c000 e01f
0x00000040: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000050: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000060: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000070: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000080: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000090: ffff ffff ffff ffff ffff ffff ffff ffff
0x000000a0: ffff ffff ffff ffff ffff ffff ffff ffff
0x000000b0: ffff ffff ffff ffff ffff ffff ffff ffff
0x000000c0: ffff ffff ffff ffff
> arm7_9 dcc_downloads enable
dcc downloads are enabled
> wait halt
> wait_halt
waiting for target halted...
target halted
> sleep 10
> poll
target state: halted
target halted in Thumb state due to breakpoint, current mode: Supervisor
cpsr: 0xa00000f3 pc: 0x7fffd2c4
> flash erase 0 0 0
erased sectors 0 through 0 on flash bank 0 in 0s 60000us
> flash write 0 test.bin 0
wrote  10000 byte from file test.bin to flash bank 0 at offset 0x00000000 in 0s
678000us (14.403577 kb/s)
> mdh 0x0 100
0x00000000: 4034 e59f 5002 e3a0 5000 e584 5003 e3a0
0x00000010: 5004 e584 201c e59f 3000 e3a0 0093 e102
0x00000020: 2028 e282 1093 e102 3007 e3c0 3028 e502
0x00000030: f004 e51f d1c0 7fff c014 e002 c000 e01f
0x00000040: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000050: ffff ffff ffff ffff ffff ffff ffff ffff
0x00000060: ffff ffff ffff ffff ffff ffff ffff ffff

The test.bin file was read from a second, identical board, running the std. olimex LCD test code.

What am I missing?, is there some magic to getting flashing working? Is there a verify step that I can enable?

Thanks in advance for any help!

2

Is the memory filled with FF after the erase command ?

3

gdisirio:
Is the memory filled with FF after the erase command ?

Strange, two attempts at replying to this, and both blocked for being inappropriate!.

It appears that the flash is erased, but I’m wondering whether the default state of the MEMMAP register isn’t presenting flash at addr. 0x0000.

4

Have you checked the contents of the test.bin file with a hex editor ?

I agree that everything looks as if it should be OK, so all possibibilites must be double checked.

/Magnus

5

teddy:
It appears that the flash is erased, but I’m wondering whether the default state of the MEMMAP register isn’t presenting flash at addr. 0x0000.

Your memory dump appears to be showing the boot loader code in the first 64 bytes of FLASH memory, which would be the case if your MEMMAP register was still at the reset value of 0x00. That should happen if the FLASH is erased, because there will be no valid checksum to cause the bootloader to turn over control to user code. You could write 0x01 to address 0xE01F C040 to switch to the user FLASH memory map to see what is actually in the first 64 bytes of your FLASH memory space?

–Dave

6

dshuman:

teddy:
It appears that the flash is erased, but I’m wondering whether the default state of the MEMMAP register isn’t presenting flash at addr. 0x0000.

Your memory dump appears to be showing the boot loader code in the first 64 bytes of FLASH memory, which would be the case if your MEMMAP register was still at the reset value of 0x00. That should happen if the FLASH is erased, because there will be no valid checksum to cause the bootloader to turn over control to user code. You could write 0x01 to address 0xE01F C040 to switch to the user FLASH memory map to see what is actually in the first 64 bytes of your FLASH memory space?

–Dave

Many thanks for the suggestions, I did make some progress... I dug out an old USB-> RS232 cable and tried the phillips RS232 flash applicaiton. This worked fine, and the 'blinking LED' application downloaded and ran successfully.

However… returning to the JTAG debugger still shows problems.

Now that the checksum is correct, the MEMMAP register is at its correct value of 1 (it was zero previously) .

Erasing the first flash bank doesn’t seem to work at all though, the data in the first sector just doesn’t change.

Confused :?

7

Got it!

Stupid mistake in the flash bank line:

flash bank lpc2000 0x0 0x40000 0 0 0 lpc2000_v2 0 12000 calc_checksum

(the zero before the clock freq.)

:oops: