LPC1114FN28/102 Flash controller documentation and ECC algorithm

[lpcware]

Content originally posted in LPCWare by m-atthias on Sat Nov 08 11:06:45 MST 2014
Dear LPC geeks,

I am happy to announce an experimental port of Mecrisp-Stellaris, a standalone native code Forth, for the breadboard friendly, DIP28 packaged LPC1114FN28/102. But this one has a tricky Flash IAP interface with 256 bytes write and 4 kb erase block size. The datasheet indicates that there is an ECC checksum over each 16 bytes which should be writeable separately, but unfortunately, I could not find ECC algorithm or Flash controller register documentation. If you know details, you could save me from disassembling and understanding the internal Boot ROM which contains the big-block in-application-flash-write code. Directly manipulating ECC or calculating ECC-adaption fill bytes could give very small individual writes needed for direct Flash compilation.

Best wishes from Germany,
Matthias

http://mecrisp.sourceforge.net/

[lpcware]

Content originally posted in LPCWare by m-atthias on Wed Dec 03 03:13:33 MST 2014
So far, I found that the Boot ROM doesn't contain an ECC algorithm but leaves its calculation to be done with a hardware implementation. It is interesting that after quickly writing 4 Words = 16 Bytes, there is a delay for a few clock cycles, maybe to let the hardware generate the checksum.

The signature hardware is used with reserved bits set and it is interesting that two clock registers are involved, one in the syscontrol region, one in the flash controller region.

There is a lock register in use in Boot ROM that might open up some more possibilities. I also identified some registers in Flash controller range that don't generate a trap which seem not to be used by Boot ROM.

Datasheets from other LPC chips indicate that a Hamming (136,128) code is used.

I managed to push the borders to have individual two-byte writes as it is helpful for the incremental compiler to have a write size that is equal to opcode size, but this gives read errors on occassional values on which ECC triggers as "correctable" errors. When no correction is possible, no trap is generated and Flash can be read undisturbed.

00005000 :  00 00 01 00 02 00 03 00   04 00 05 00 06 00 07 00  | ........  ........ |
00005010 :  08 00 09 00 0A 00 0B 00   0C 00 0D 00 0E 00 0F 00  | ........  ........ |
00005020 :  10 00 11 00 12 00 13 00   14 00 15 00 16 00 17 00  | ........  ........ |
00005030 :  18 00 19 00 1A 00 1B 00   1C 00 0D 00 1E 00 1F 00  | ........  ........ |

Another try:

00005000 :  00 00 01 01 02 02 03 03   04 04 05 05 06 06 07 07  | ........  ........ |
00005010 :  08 08 09 09 0A 0A 0B 0B   0C 0C 0D 0D 0E 0E 0B 0F  | ........  ........ |
00005020 :  10 10 11 11 12 12 13 13   14 14 15 15 16 16 17 17  | ........  ........ |
00005030 :  18 18 19 39 1A 1A 1B 1B   1C 1C 1D 1D 1E 1E 1F 1F  | ...9....  ........ |
00005040 :  20 20 21 21 22 22 23 23   24 04 25 25 26 26 27 27  |   !!""##  $.%%&&'' |
00005050 :  28 28 29 29 2A 2A 2B 2B   2C 2C 2D 2D 2E 2E 2F 2E  | (())**++  ,,--../. |
00005060 :  30 30 31 31 32 32 33 33   34 34 35 35 36 36 37 37  | 00112233  44556677 |
00005070 :  38 38 39 39 BA 3A 3B 3B   3C 3C 3D 3D 3E 3E 3F 3F  | 8899.:;;  <<==>>?? |

So this leaves me with a final question:

Is there a bit to switch off ECC for maybe factory testing purposes or force the Flash to a "marginal read mode" without ECC ? It is a really tedious search to write random numbers into identified registers to see if a known-bad ECC corrected value suddenly reads right.

Pushing ECC bits into an always-wrong-but-uncorrectable state would be a solution, too.

... Dear NXP - you design nice chips, and my kudos for having an ARM Cortex in DIP28 package, but why on earth did you decide to not describe your Flash controller bits ?

[lpcware]

Content originally posted in LPCWare by m-atthias on Fri Nov 21 09:10:15 MST 2014
Some fresh research results:

Bit $40 in register $4003C000 which is toggled many, many times in the boot rom code controls memory remap of the lower memory. This gives rise to a 2 kb long block of maybe calibration values or chip specific constants if the same Bootloader is used across different chips. Its dump is attached - all mysterious locations are resolved within.

I also probed registers in the Flash controller address range and made a map which ones run into an address invalid trap. This shows nicely which registers could be in use.

Matthias

[lpcware]

Content originally posted in LPCWare by m-atthias on Wed Nov 12 03:49:16 MST 2014
One major thing that is puzzling me are mysterious locations that are mostly read directly.
Normally, those locations are just in user flash.
I assume some memory remapping, but if boot rom is mapped to address zero, this just gives some opcodes back.
When mapped to SRAM then I would expect at least some str's to these locations. Another remapping in use ?

434
438
43C
440
44C
450
454
458
45C
470
490

520
5B0
5B4
5BC
5C8
5CC
5D0
5DC
5E0
5E8
5EC
5F0
5F4

[lpcware]

Content originally posted in LPCWare by m-atthias on Wed Nov 12 03:15:51 MST 2014
I just forgot to add the Calltrace.

Matthias

[lpcware]

Content originally posted in LPCWare by m-atthias on Wed Nov 12 00:25:19 MST 2014
I found a path into the jungle, and for those interested here the current state of my research. It is difficult to run the binary in emulator because it depends on initial register values not documented elsewhere - worst case of Flash controller documentation. It seems to be a good idea to catch all peripheral register access manually and fill in values extracted from real chip step by step when necessary. Help still greatly appreciated !