flash erase 0 0 26 fails with wiggler on lpc2148

Development Boards MicroMod
1

This is very strange. I can program the Olimex sample project test (blinks LED’s in an alternating pattern each for 500ms) using the lpc21isp utility. However; when I try to do the equivalent operation with the wiggler JTAG I find that I cannot erase the flash.

my configuration is:openOCD rev 284.

#daemon configuration
telnet_port 4444
gdb_port 3333

interface parport
parport_cable wiggler
jtag_speed 0

reset_config trst_and_srst 

#jtag scan chain
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 333
jtag_ntrst_delay 333

daemon_startup reset
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4
run_and_halt_time 0 30
#flash working_area 0 0x00000000 0x400000 nobackup
working_area 0 0x40000000 0x40000 nobackup
flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 0 12000 calc_checksum

The commands and responses from the telent localhost 4444 session are:

> halt
requesting target halt...
target already halted
> mdd 0 32
Command mdd not found
> mdw 0 32
0x00000000: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9205f84 e51ffff0 e59ff014 
0x00000020: 00000040 000002e0 000002cc 000002e0 000002e0 000002a4 000002b8 00000000 
0x00000040: e59f0078 e321f0db e1a0d000 e2400004 e321f0d7 e1a0d000 e2400004 e321f0d1 
0x00000060: e1a0d000 e2400004 e321f0d2 e1a0d000 e2400004 e321f0d3 e1a0d000 e2400004 
> flash erase 0 0 1
erased sectors 0 through 1 on flash bank 0 in 0s 81559us
> mdw 0 32         
0x00000000: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9205f84 e51ffff0 e59ff014 
0x00000020: 00000040 000002e0 000002cc 000002e0 000002e0 000002a4 000002b8 00000000 
0x00000040: e59f0078 e321f0db e1a0d000 e2400004 e321f0d7 e1a0d000 e2400004 e321f0d1 
0x00000060: e1a0d000 e2400004 e321f0d2 e1a0d000 e2400004 e321f0d3 e1a0d000 e2400004

I expected to see F’s. If I can’t erase the flash I will not be able to program my own code into it. Any help / advice welcome

Thanks

–mgross

2

This might be a case of the blind leading the blind but I’m having similar problems with an LPC2119 and ARM-USB-OCD.

Have a look at the output from openocd server itself rather than what telnet reports.

In my case, telnet comes back with a successful erase ( or write ) message (as you’re getting) but the operation actually fails and the server ouputs timeout errors. Flash is left untouched.

3

Thanks,

I started up the openocd with the -d 4 option. It pushes out a lot of debug but nothing that looks like its an error. (should I post the output to the forum?)

–mgross

4

markgross:
Thanks,

I started up the openocd with the -d 4 option. It pushes out a lot of debug but nothing that looks like its an error. (should I post the output to the forum?)

–mgross

You shouldn’t need the “-d 4” option; this is the kind of output I was getting without it when I tried to erase flash:

[root@athlon26 ~]# openocd -f /root/OPENOCD/lpc2xxx_armusbocd.cfg
Info:    openocd.c:93 main(): Open On-Chip Debugger (2007-09-05 09:00 CEST)
Warning: arm7_9_common.c:742 arm7_9_assert_reset(): srst resets test logic, too
Info:    server.c:67 add_connection(): accepted 'telnet' connection from 0
Error:   armv4_5.c:591 armv4_5_run_algorithm(): timeout waiting for algorithm to complete, trying to halt target

I’ve actually got my erasing and flashing going correctly now, at least from a telnet session. As far as I can tell, it is necessary to do a hardware reset before doing any flashing or erasing; it seems that even when other operations (eg: mdw 0 100) appeared to work OK, they returned incorrect data. “reset run_and_halt” cured the problem.

The first thing I do now is to check the telnet output from

“flash info 0”. The very last line should give the correct pll clock speed; in my case this is:

lpc2000 flash driver variant: 1, clk: 58982

That 58982 agrees with the “flash bank” line in my cfg file. Before doing the hardware reset, the clock was reported as 0.

Other things:

These lines in your cfg file look fishy!

working_area 0 0x40000000 0x40000 nobackup
flash bank lpc2000 0x0 0x7D000 0 0 0 lpc2000_v2 0 12000 calc_checksum

According to my nxp selection card your 2148 has 512k flash and 40k ram so your working area would be 0xA000 rather than 0x40000 (not that it would make any difference to your current problem).

Also, in the flash bank line, is there a reason for leaving 12k at the top of flash? 512k would be 0x80000 rather than 0x7D000 but I’ve seen 0x7D000 used in other cfg files and never knew why.

Last thought, is your clk really 12000 or is that just the xtal freq?

Do post up anything you find!

5 
working_area 0 0x40000000 0x40000 nobackup

Yes I think this is wrong. I think the working_area is the RAM space of the part. it should be:

working_area 0 0x40000000 0x8000

However; I don’t think this setting affects flash operations at all.

flash info shows some issues:

> flash info 0
#0: lpc2000 at 0x00000000, size 0x0007d000, buswidth 0, chipwidth 0
        #0: 0x00000000 (0x1000 4kB) erase state unknown, protected
        #1: 0x00001000 (0x1000 4kB) erase state unknown, protected
        #2: 0x00002000 (0x1000 4kB) erase state unknown, protected
        #3: 0x00003000 (0x1000 4kB) erase state unknown, protected
        #4: 0x00004000 (0x1000 4kB) erase state unknown, protected
        #5: 0x00005000 (0x1000 4kB) erase state unknown, protected
        #6: 0x00006000 (0x1000 4kB) erase state unknown, protected
        #7: 0x00007000 (0x1000 4kB) erase state unknown, protected
        #8: 0x00008000 (0x8000 32kB) erase state unknown, protected
        #9: 0x00010000 (0x8000 32kB) erase state unknown, protected
        #10: 0x00018000 (0x8000 32kB) erase state unknown, protected
        #11: 0x00020000 (0x8000 32kB) erase state unknown, protected
        #12: 0x00028000 (0x8000 32kB) erase state unknown, protected
        #13: 0x00030000 (0x8000 32kB) erase state unknown, protected
        #14: 0x00038000 (0x8000 32kB) erase state unknown, protected
        #15: 0x00040000 (0x8000 32kB) erase state unknown, protected
        #16: 0x00048000 (0x8000 32kB) erase state unknown, protected
        #17: 0x00050000 (0x8000 32kB) erase state unknown, protected
        #18: 0x00058000 (0x8000 32kB) erase state unknown, protected
        #19: 0x00060000 (0x8000 32kB) erase state unknown, protected
        #20: 0x00068000 (0x8000 32kB) erase state unknown, protected
        #21: 0x00070000 (0x8000 32kB) erase state unknown, protected
        #22: 0x00078000 (0x1000 4kB) erase state unknown, protected
        #23: 0x00079000 (0x1000 4kB) erase state unknown, protected
        #24: 0x0007a000 (0x1000 4kB) erase state unknown, protected
        #25: 0x0007b000 (0x1000 4kB) erase state unknown, protected
        #26: 0x0007c000 (0x1000 4kB) erase state unknown, protected
lpc2000 flash driver variant: 2, clk: 0
>

clk: 0 ??? hmm…

My USB JTAG should be here in a couple of days, I wonder what it will say…

BTW I think the hardware works with the USB JTAG, 2 weeks ago I was with a friend that had the usb jtag and it worked then. I’m thinking its something with the P-Port JTAG I’m using, my parallel port (set to bi-directional) or something with the OCD (build 284)

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

I think is correct. I read somewhere that you should to omit the last flash block as thats where the bootloader / ISP lives and you cannot write to it anyway. (some sort of protection)

6

clk: 0 ??? hmm…

Well yes indeed! I suspect your startup.s / boot.s / crt.s or whatever is setting up P and or M in PLLCFG such that your actual clock is not 12 Mhz as in your cfg file.

Unless your 2148 is a fiendishly weird machine the flash info is definitely wrong also. (It looks just like mine did until I sorted out the cfg file) I think you should be seeing a nice list of 64 8k blocks like so:

> flash info 0
#0: lpc2000 at 0x00000000, size 0x00020000, buswidth 0, chipwidth 0
        #0: 0x00000000 (0x2000 8kB) erase state unknown, protected
        #1: 0x00002000 (0x2000 8kB) erase state unknown, protected
        #2: 0x00004000 (0x2000 8kB) erase state unknown, protected
        #3: 0x00006000 (0x2000 8kB) erase state unknown, protected
etc. up to #63

change that flash bank line in your cfg from 0x7D000 to 0x80000. As you rightly say you can’t do any damage as the write/erase commands will not write to the last block.

7

I don’t think my problem has much to to with any startup code running on the 2148. The badness happens even when its fully erased (using the ISP interface).

However; I’m very eager to have a look at your OCD config file. could you post it?

8

Hi,

a few notes on LPC21xx flashing:

  • if “mdw 0x0 ” shows wrong content (e.g. not 0xff when the flash is all erased) you might actually be seeing the first 64 byte from SRAM, because the exception vectors got remapped. Check the memmap setting (some register inside the LPC).

  • Originally the lpc2000_v2 variant required the flash size to be the amount of user-accessible flash, which is an “even” number (128k, 256k, …) on all but the largest LPCs (512K). That requirement got lifted, and the code translates 0x80000 to the 0x7d000 bytes the user can write/erase.

  • Working area affects all lpc2000 flash operations, because these rely on small code sequences running in LPC2000 RAM.

  • The LPC2000 flash configuration syntax is:

flash bank lpc2000 0 0 <target#> <lpc_variant> [calc_checksum]

Your flash bank line is bogus, it has an excessive 0 between the variant “lpc2000_v2” and the frequency “12000”.

  • Your sector layout is fine, just what a LPC2148 should look like (see LPC214x UM).

  • The frequency from the .cfg file has to match the current frequency at the time of flashing, but in most cases a value that’s of by a factor of 6 worked just fine (e.g. 12000 when the chip was running at 70mhz). Of course you should always use the correct setting, I just wanted to say that this isn’t likely to be the root of your problems.

Best regards,

Dominic

9

I know nobody answered when myself and others suggested auto configuration of known chips.

This seems a mistake to me as a LOT of the support issues are down to getting a working .cfg file.

As I mentioned before with Auto Configuration then no .cfg file would be needed for most people with detectable JTAG interfaces like FTDI based ones.

Having port numbers, interface type and chip settings in the same file makes life harder too. I wanted to setup debugging on an STM32 board and there is no .cfg file out there that will work. I will have to patch together information from two places to make it work.

What compiler is the yagarto version of OpenOCD built on ?

I suppose I should try and have a go at doing some hacking myself!

10

Here is my cfg Mark; I see you have Dominic on your case so I’ll keep my noob ideas quiet to avoid confusion / embarrassment!. Good luck.

#daemon configuration
#from: http://psas.pdx.edu/OlimexLPC2148Setup/
#usage:
#   openocd -f /root/eclipse/ARM/lpc2xxx_armusbocd.cfg
#   telnet localhost 4444
# For more information about the configuration files, take a look at:
# http://openfacts.berlios.de/index-en.phtml?title=Open+On-Chip+Debugger

telnet_port 4444
gdb_port 3333

#interface
interface ft2232
ft2232_device_desc "Olimex OpenOCD JTAG A"
ft2232_layout "olimex-jtag"
ft2232_vid_pid 0x15BA 0x0003
#ft2232_latency 10
jtag_speed 3

#use combined on interfaces or targets that can't set TRST/SRST separately
#Defines the type of reset configuration supported by the JTAG interface and the connected devices.
reset_config trst_and_srst srst_pulls_trst

#jtag scan chain
#format L IRC IRCM IDCODE (Length, IR Capture, IR Capture Mask, IDCODE)
jtag_device 4 0x1 0xf 0xe

#target configuration
#target <type> <startup mode>
daemon_startup reset
#target arm7tdmi <reset mode> <chainpos> <endianness> <variant>
#target arm7tdmi little run_and_init 0 arm7tdmi-s_r4
target arm7tdmi little run_and_halt 0 arm7tdmi-s_r4

#run_and_halt_time <target#> <time_in_ms>
# The amount of time the debugger should wait after releasing reset before it asserts a debug request.
# This is used by the 'run_and_halt' and 'run_and_init' reset modes.
run_and_halt_time 0 30


#target_script 0 reset scripts/openocd_flash_lpc2148.script  (not necessary with eclipse ROB)

# working_area <target#> <address> <size> <'backup'|'nobackup'>
# Specifies a working area for the debugger to use. LPC2119 has 16k ram at 0x4000 0000 to 0x4000 3FFF
working_area 0 0x40000000 0x4000 nobackup 

#flash configuration. LPC2119 has 128k ram at 0x0000 0000 to 0x0000 1FFF
# this is the new form of flash bank. 58982 is the clock (pll) not xtal freq:
flash bank lpc2000 0 0x20000 0 0 0 lpc2000_v1 58982 calc_checksum
11

Thanks for all the help. I have the new ARM-USB-OCD, and to my horror it fails to work in the exact same way!

So as bizzar as it may seem I have 2 Ubuntu 7.10 systems one is a desktop (this is the one where the jtag fails to erase flash) and a laptop where the ARM-USB-OCD works. both running the same Ubuntu kernel.

I’ve copied the openocd binary from the laptop to the desktop and the failure still happens on the desktop. Hence I don’t think its a build issue.

Looking at the ldd output and checking the md5sum’s of all the dependent libraries shows that the binary dependencies are all identical.

This is just ubber strange! What’s left? Network stack? Real time effects? (the desktop is an older 3GHz dual core P4) The T43 laptop is an older Centrino (1.8GHz Pentium M) Both are running 32 bit distros (i386).

I can’t think of what the heck is the deal. very strange!!!