Hello Marcelo, What you see is bootrom code that gets automatically mapped to 0 if there is no user code or it's invalid.
"The interrupt vectors residing in the boot block of the on-chip flash memory also become active after reset, i.e., the bottom 64 bytes of the boot block are also visible in the memory region starting from the address 0x0000 0000. The reset vector contains a jump instruction to the entry point of the flash boot loader software." 00000000 LDR R4, =0x3FFF8000 00000004 LDR R5, =0xFFFFBFFF 00000008 LDR R6, [R4] 0000000C AND R6, R5, R6 00000010 STR R6, [R4] 00000014 LDR PC, =0x7FFFE040 0x7FFFE040 is the bootrom entrypoint. "3.1.1 Criterion for Valid User Code Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014) should contain the 2’s complement of the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0. The boot loader code disables the overlaying of the interrupt vectors from the boot block, then checksums the interrupt vectors in sector 0 of the flash. If the signatures match then the execution control is transferred to the user code by loading the program counter with 0x0000 0000. Hence the user flash reset vector should contain a jump instruction to the entry point of the user application code." My guess is that FlashMagic automatically patches the checksum to be correct. On Wed, Dec 16, 2009 at 14:47, Marcelo Utikawa da Fonseca <[email protected]> wrote: > Thank you! > > I will try FlashMagic later because I do not have Windows on my PC. > About the data in first 64 bytes I do not understand about them but they are > in the flash! > Please see the below logs showing this strange behaviour. I am using the > telnet to send commands: > > 1) Memory containing correct data: > >> mdw 0 0x20 > 0x00000000: e59ff018 e59ff018 e59ff018 e59ff018 e59ff018 b9206e58 e51ff120 > e59ff010 > 0x00000020: 00000038 00001244 00001258 0000121c 00001230 0000126c e59f0198 > e321f0db > 0x00000040: e1a0d000 e2400004 e321f0d7 e1a0d000 e2400004 e321f0d1 e1a0d000 > e2400004 > 0x00000060: e321f0d2 e1a0d000 e2400040 e321f0d3 e1a0d000 e2400040 e321f0df > e1a0d000 > > 2) Now I do a erase and show the data again: > >> flash erase_sector 0 0 0 > erased sectors 0 through 0 on flash bank 0 in 0.171872s >> mdw 0 0x20 > 0x00000000: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > 0x00000020: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > 0x00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > 0x00000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > > 3) The flash seems to be erased. Now I turn off the board, turn on again and > reconnect the OpenOCD. Here is the result: > >> halt > target state: halted > target halted in Thumb state due to debug-request, current mode: Supervisor > cpsr: 0xa00000f3 pc: 0x7fffe154 >> mdw 0 0x20 > 0x00000000: e59f4018 e59f5010 e5946000 e0056006 e5846000 e51ff004 7fffe040 > ffffbfff > 0x00000020: 3fff8000 00000000 00000000 00000000 00000000 00000000 00000000 > 00000000 > 0x00000040: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > 0x00000060: ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff > ffffffff > > In the J-Flash software, the command to read back the entire chip shows only > 0xff but the J-Link Commander can read exactly the same data: > > SEGGER J-Link Commander V3.96d ('?' for help) > Compiled Nov 21 2008 19:00:17 > DLL version V3.96d, compiled Nov 21 2008 18:59:52 > Firmware: J-Link ARM V6 compiled Jun 30 2009 11:06:04 > Hardware: V6.00 > S/N : 156002960 > OEM : IAR > VTarget = 3.319V > Info: TotalIRLen = 4, IRPrint = 0x01 > Found 1 JTAG device, Total IRLen = 4: > Id of device #0: 0x4F1F0F0F > Found ARM with core Id 0x4F1F0F0F (ARM7) > ETM V1.2: 1 pairs addr.comp, 0 data comp, 4 MM decs, 1 counters > RTCK reaction time is approx. 189ns > Using adaptive clocking instead of fixed JTAG speed. > J-Link>mem 0 0x80 > 00000000 = 18 40 9F E5 10 50 9F E5 00 60 94 E5 06 60 05 E0 > 00000010 = 00 60 84 E5 04 F0 1F E5 40 E0 FF 7F FF BF FF FF > 00000020 = 00 80 FF 3F 00 00 00 00 00 00 00 00 00 00 00 00 > 00000030 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00000040 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > 00000050 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > 00000060 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > 00000070 = FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF > J-Link> > > What can be wrong? > > Best regards, > Marcelo Utikawa da Fonseca > > Nico Coesel escreveu: > > The first 64 bytes must always be erased. Try to use flashmagic instead of > OpenOCD. > > These controllers use flash with ECC therefore you cannot program the flash > partially / patch single bytes. > > Nico Coesel > > > > > -----Original Message----- > From: [email protected] [mailto:openocd- > [email protected]] On Behalf Of Marcelo Utikawa da > Fonseca > Sent: woensdag 16 december 2009 13:54 > To: [email protected] > Subject: Re: [Openocd-development] Problem when tryng to flash LPC2368 > > Hi again! > > I am still having problems to write the flahs in an LPC2368. > > Now I know that the first 64 bytes is never erased. There is always data > in this area. 95% of the write errors are caused because the data is not > correctly programmed in this area. > In the J-Flash software, this area have data after a erase so I think > that the data in this area is correct. > I am using J-Link in both OpenOCD and J-Flash. I have tried a programmer > derivated from axm0432 and I receive the same results... > > Could this be a bug in OpenOCD? It cannot write in this situation but > J-Flash can so the problem is not in the hardware or the programmer > because they are the same. > > Best regards, > Marcelo Utikawa da Fonseca > > Marcelo Utikawa da Fonseca escreveu: > > > 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? > > Logs: > > Starting OpenOCD: > > $ sudo openocd -f jtec.cfg -f lpc2368.cfg > [sudo] password for utikawa: > Open On-Chip Debugger 0.2.0 (2009-12-14-11:51) Release > $URL: > http://svn.berlios.de/svnroot/repos/openocd/tags/openocd- > > > 0.2.0/src/openocd.c > > > $ > For bug reports, read > > > http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > > 100 kHz > jtag_nsrst_delay: 100 > jtag_ntrst_delay: 100 > Info : device: 4 > Info : deviceID: 67330064 > Info : SerialNumber: S6 > Info : Description: Dual RS232 A > Info : JTAG tap: lpc2368.cpu tap/device found: 0x4f1f0f0f (mfg: 0x787, > part: 0xf1f0, ver: 0x4) > Info : JTAG Tap/device matched > Warn : EmbeddedICE version 7 detected, EmbeddedICE handling might be > > > broken > > > Starting GDB without run erase in J-Flash: > > arm-elf-gdb -x gdbinit_minilpc.conf > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf". > Setting up for the Tecnequip MiniLPC. > The target is assumed to be little endian > The target may not be able to correctly handle a memory-write-packet-size > of 1024 bytes. Change the packet size? (y or n) [answered Y; input not > from terminal] > 0x00001a04 in ?? () > Loading section startup, size 0x204 lma 0x0 > Loading section text, size 0x106f0 lma 0x204 > Loading section .data, size 0x878 lma 0x108f4 > Start address 0x0, load size 69996 > Transfer rate: 3 KB/sec, 972 bytes/write. > Breakpoint 1 at 0x234 > Note: automatically using hardware breakpoints for read-only addresses. > > It never reaches main(). > > Starting GDB after a erase in J-Flash: > > arm-elf-gdb -x gdbinit_minilpc.conf > GNU gdb 6.8 > Copyright (C) 2008 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf". > Setting up for the Tecnequip MiniLPC. > The target is assumed to be little endian > The target may not be able to correctly handle a memory-write-packet-size > of 1024 bytes. Change the packet size? (y or n) [answered Y; input not > from terminal] > 0x7fffe152 in ?? () > Loading section startup, size 0x204 lma 0x0 > Loading section text, size 0x106f0 lma 0x204 > Loading section .data, size 0x878 lma 0x108f4 > Start address 0x0, load size 69996 > Transfer rate: 3 KB/sec, 972 bytes/write. > Breakpoint 1 at 0x234 > Note: automatically using hardware breakpoints for read-only addresses. > > Breakpoint 1, 0x00000234 in main () > (MiniLPC) > > > Best regards, > Marcelo Utikawa da Fonseca > > > --------------------------------------------- > Tecnequip Tecnologia em Equipamentos > Endereço/Address: R. Ganges, 557 > Cidade/City: São Paulo > Estado/State: SP > País/Country: Brasil > CEP/Postal Code: 03445-030 > Fone/Phone: 55-11-20937199 > FAX: 55-11-29412289 > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > > --------------------------------------------- > Tecnequip Tecnologia em Equipamentos > Endereço/Address: R. Ganges, 557 > Cidade/City: São Paulo > Estado/State: SP > País/Country: Brasil > CEP/Postal Code: 03445-030 > Fone/Phone: 55-11-20937199 > FAX: 55-11-29412289 > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > > > > --------------------------------------------- > Tecnequip Tecnologia em Equipamentos > Endereço/Address: R. Ganges, 557 > Cidade/City: São Paulo > Estado/State: SP > País/Country: Brasil > CEP/Postal Code: 03445-030 > Fone/Phone: 55-11-20937199 > FAX: 55-11-29412289 > > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development > > -- WBR, Igor _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
