Hi, (First of all, I'm new to the list) I've found this very old thread (2009) when browsing the web for searching a solution to a similar problem (LPC2388 instead of LPC2368 but same symptoms).
Extracting some parts of the old discussion : <marcelo.fons...@tecnequip.com.br> wrote: > Hi! > First of all, I am new to this list. > My name is Marcelo Fonseca. I work in a Brazilian design house and have > experience with LPC21xx and LPC23xx from NXP and i.MX family from Freescale. > I am having problems to write an LPC2368 with our custom board. > I can write it with a J-Link and J-Flash software from Segger. > In OpenOCD all seems to work but many times there are errors when trying > to write the flash memory using the GDB. > If I run a erase in the J-Flash software I have no error and OpenOCD > succesfully write to the flash memory. > When I run the "flash erase_sector" command in OpenOCD, J-Flash says > that the flash is blank but I need to run a erase in J-Flash to write > the flash using OpenOCD. > PS.: sometimes I can write in OpenOCD without having to run a erase in > J-Flash... > > Can anyone help me to solve this issue? <marcelo.fons...@tecnequip.com.br> wrote: > Great, now it is working! :-) > > I put the following line in my gdb config file: > > monitor mwb 0xe01fc040 0x01 > > Thank you! and few messages later : >Hi again! >Unfortunatelly the problem was not solved. Sometimes the write is ok but >many times I have error when trying to write the memory. >If I send the write command two or three times, the write is succesful. >It looks like some bits are not cleared by the write command. >Could this be some configuration problem or it is the openocd itself I had the same problem here (I use GDB with Eclipse to develop and don't want to use FlashMagic or other loading software through RS232 each time to load my program to the flash before the debug) - the first time, loading with gdb, the flash was correctly written. Running and debugging flawless. - the second time, flashing doesn't reported any errors, but impossible to start, debug, etc. (When resetting the board I saw that the microboot don't branch to the flash (probably because of the checksum invalid in memory) and was waiting on the RS232 link). - the next time, loading ok etc. The problem was only the flash writting step with gdb "load" command. If I used FlashMagic or other "home made" loading software, I can debug with GDB flawless. My problem was : how to make gdb "load" work with OpenOCD for my LPC2388 based board. Browsing another forum, I've found the fix (http://forum.sparkfun.com/viewtopic.php?t=8961 solution posted by "daa"). The issue was a problem of clock speed for the flash (was set to 4000 for lpc2000 flash driver). Our software set PLL for the board to run à 59Mhz but we set 4000Khz, then when loading, the flash memory was not written correctly, resulting in an invalid program. Then the microboot of the LPC detected an invalid checksum and wait on RS232 link for a new software to be loaded ; I suppose in this case the PLL is not used and the board use directly the 4Mhz internal clock ==> This time the flash writting was OK. Loading my new program was OK and then the clock speed was again set to 59Mhz ==> Next flash writting will fail in this case etc. So, I post my configuration file for LPC2388 (derived from LPC2378 configuration file found in openocd) with flash frequency set to 60000Khz : ############################################################################# # NXP LPC2378 ARM7TDMI-S with 512kB Flash and 32kB Local On-Chip SRAM (58kB total) telnet_port 4444 gdb_port 3333 # # Olimex ARM-USB-OCD # # http://www.olimex.com/dev/arm-usb-ocd.html # interface ft2232 ft2232_device_desc "Olimex OpenOCD JTAG" ft2232_layout "olimex-jtag" ft2232_vid_pid 0x15BA 0x0003 if { [info exists CHIPNAME] } { set _CHIPNAME $CHIPNAME } else { set _CHIPNAME lpc2388 } if { [info exists ENDIAN] } { set _ENDIAN $ENDIAN } else { set _ENDIAN little } if { [info exists CPUTAPID ] } { set _CPUTAPID $CPUTAPID } else { set _CPUTAPID 0x4f1f0f0f } #delays on reset lines jtag_nsrst_delay 200 jtag_ntrst_delay 200 # LPC2000 -> SRST causes TRST reset_config trst_and_srst srst_pulls_trst jtag newtap $_CHIPNAME cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id $_CPUTAPID set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME arm7tdmi -endian $_ENDIAN -chain-position $_TARGETNAME -variant arm7tdmi-s_r4 # LPC2388 has 64kB of SRAM on its main system bus (so-called Local On-Chip SRAM) $_TARGETNAME configure -work-area-virt 0 -work-area-phys 0x40000000 -work-area-size 0x10000 -work-area-backup 0 $_TARGETNAME configure -event reset-init { # Force target into ARM state soft_reset_halt #do not remap 0x0000-0x0020 to anything but the flash mwb 0xE01FC040 0x01 } # LPC2388 has 512kB of FLASH, but upper 8kB are occupied by bootloader. # After reset the chip uses its internal 4MHz RC oscillator # flash bank <name> <driver> <base> <size> <chip_width> <bus_width> <target> [driver_options] # Note : driver_options=lpc2000_v2 (for LPC2388 it is the good model) freq=60000 calc_checksum (to force @0x14 checksum to be calculated correctly at each flash) # Note : the frequency (here 60000) is very important. When set to 4000 (for 4Mhz internal RC oscillator) (was de previously used value) it caused problem when writting to Flash, causing the board to started in a "bricked" state set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME lpc2000 0x0 0x0007D000 0 0 $_TARGETNAME lpc2000_v2 60000 calc_checksum # 4MHz / 6 = 666kHz, so use 500 jtag_khz 500 ######################################################################### This configuration file work but I'm not sure if I should not add some code in the reset-init section to set the usage of the PLL and the external oscillator at each reset. Can I in this case increase the jtag_khz parameter ? Regards -- Luc _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
