I just realized I hit "reply" for all previous emails, so I did not send them to the list. I'll copy paste them below.
I am converting the elf to bin to be able to correct the checksum afterwards with a little tool I wrote. This way openocd does not emit warnings about the verification failiure. Maybe this has been fixed since, but when I first started programming with it, it could replace the checksum with the correct value during write, but could not verify the write afterwards. I had no idea, what the register setting did. At first I used the script without that command, but it kept doing the same thing it is doing now. I started looking around, and found it on some forum that it *should* be useful. (It wasn't) I searched the manual to learn what it does, without success. It's a shame that the register addresses in the manual are separated with spaces, and that's causing a lot of headaches when searching for registers by address. Thanks for the input Peter, I found it now. The lpc17xx is a cortex-m3, yes. I'll be at work in a few hours, and I'll provide you with a programming output. Here are my past emails: 1. (in reply to freddie choppin) As far as I understand, reset halt is not supported on my target because srst pulls trst. Regards, Ákos 2. ( in reply to laurent gauch) Every second one works. It doesn't matter if the device is blank or not, or when the programmer is connected. Suppose code is running, but it it faulty. Connect the programmer, run openocd once, it does not work. Run openocd twice, and it works. If the programmer is disconnected and connected again between the programmings, it does not matter. I usually leave it on for debugging, so I connect it when I get to work, and disconnect after several programming cycles. If I accidently do 3 programmings, it doesn't work again. After the fourth it works. So every other programming is successful. Ákos 3. (in reply to freddie choppin) I'm not sure I understand what should I change to "separate"...? Regards, Ákos 4. (in reply to freddie choppin) I just realized I left my programmer at work, so I'll be back to you tomorrow. Ákos On 20 October 2011 03:50, Peter Stuge <pe...@stuge.se> wrote: > Andreas Fritiofson wrote: >> But what is the mwb 0x400FC040 0x01 doing? > > MEMMAP > Bit 0 MAP Reset value 0 > 0 Boot mode. A portion of the Boot ROM is mapped to address 0. > 1 User mode. The on-chip Flash memory is mapped to address 0. > > 6. Debug memory re-mapping > - > Following chip reset, a portion of the Boot ROM is mapped to address > 0 so that it will be automatically executed. The Boot ROM switches > the map to point to Flash memory prior to user code being executed. > In this way a user normally does not need to know that this > re-mapping occurs. > > However, when a debugger halts CPU execution immediately following > reset, the Boot ROM is still mapped to address 0 and can cause > confusion. Ideally, the debugger should correct the mapping > automatically in this case, so that a user does not need to deal with > it. > > > So yes indeed this should be taken care of in openocd. And it should > be the default. > > > //Peter > _______________________________________________ > Openocd-development mailing list > Openocd-development@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/openocd-development > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
