Data written to flash on LPC11C24 gets corrupted

[zyp]

I'm getting started with LPC11C24 here, and flash writes seems to get corrupted.

(gdb) load
Loading section .vectors, size 0x130 lma 0x0
Loading section .init_array, size 0x4 lma 0x130
Loading section .text, size 0x1c0 lma 0x134
Loading section .data, size 0x4 lma 0x2f4
Start address 0x134, load size 760
Transfer rate: 3 KB/sec, 190 bytes/write.
(gdb) compare-sections 
Section .vectors, range 0x0 -- 0x130: MIS-MATCHED!
Section .init_array, range 0x130 -- 0x134: MIS-MATCHED!
Section .text, range 0x134 -- 0x2f4: MIS-MATCHED!
Section .data, range 0x2f4 -- 0x2f8: matched.
warning: One or more sections of the remote executable does not match the loaded file
(gdb) x/wx 0x130
0x130 <_init_array_start>:  0x42900093
(gdb) detach
Detached from remote process.
(gdb) x/wx 0x130
0x130 <_init_array_start>:  0x00000139

I'd expect .vectors to mismatch, due to the signature generation, but not the other sections. Since .init_array contains an invalid address, the processor hardfaults during startup code.

[gsmcmullin]

This may have been broken by my refactoring of the LPC code. Can you check if you have the same problem with v1.6-rc0. I unfortunately don't have any LPC11C24 to test with.

[dlaw]

The first 512 bytes of the address space are mapped to boot ROM by default. Once you write the SYSMEMREMAP register (address 0x40048000) to have a value of 2, those 512 bytes are mapped to flash and all sections will match. The LPC bootloader automatically does this upon detecting valid user code, but the bootloader cannot run while you are holding the chip in reset with a debugger. See section 3.5.1 of the manual. In gdb, you can set {int}0x40048000 = 2 to achieve the same result.

In summary, this is not a bug with the LPC refactoring.

[zyp]

That doesn't explain why my code were hardfaulting. When the bootloader is mapped in, it should run before anything gets to the entry point of my code.

Unfortunately I put the project I were evaluating LPC11C for on hold, so I never got around to retesting, and right now I'm on vacation so I won't be able to for a while either.

[esden]

Is there a verdict on this issue?

[zyp]

Well, I never got back to that project, so I haven't concluded with anything.

[dlaw]

I am currently developing for LPC824, LPC1549, and LPC11U68 with the Black Magic Probe, and I have not experienced this issue. I do observe section mismatches, as described in zyp's initial report, until the SYSMEMREMAP register is set.

[esden]

Should the Black Magic Probe code set the remap register when flashing the firmware? Or would that have some other negative impact?

[dlaw]

I think the choice of whether to set the remap register should be left to the user. I set it in my gdbinit file most of the time, but every once in a while I disable that in order to step through the ROM bootloader with the debugger. Note that the address of the register differs between different LPC product lines.

[esden]

So I think we should include this in the wiki so that people can find it. I think this should be added at least to the FAQ section. Can you provide us with the needed line for .gdbinit and the exact chip you are using? The text should then probably include some information about how to find the register for a similar LPC chip if it does not work for the user.

[dlaw]

For the LPC8xx/LPC11xx, the relevant lines are

set mem inaccessible-by-default off
set {int}0x40048000 = 2

The exact chip I'm using is the LPC824 and the name of the register in question is "SYSMEMREMAP".

[esden]

Thank you! I have added an item to the FAQ. Feel free to improve the wiki. Thank you very much for the help and your contribution.