NXP LPC802 Flashing - Printable Version +- EmBitz (https://www.embitz.org/forum) +-- Forum: EBlink (https://www.embitz.org/forum/forum-3.html) +--- Forum: Scripts (https://www.embitz.org/forum/forum-7.html) +--- Thread: NXP LPC802 Flashing (/thread-160.html) |
NXP LPC802 Flashing - jdubois - 11-04-2023 Working with some custom scripts I've written to use NXP LPC chips with EBlink, I've run into a stumbling point. The LPC802 chip has 16K of flash arranged as either 16 sectors of 1K each, or 256 pages of 64 bytes each. The last two pages (254 & 255) are mapped on the chip to ROM instead of the flash, so you cannot program them. Using the 1024 byte sector arrangement instead of the 64 byte page arrangement is much faster to erase and program. But using this, the last sector is actually 896 bytes instead of 1024. There doesn't seem to be any good way to tell EBlink about this uneven sized final sector. The first approach is to simply use the 64 byte page arrangement. This works, but is very slow to erase and write 256 individual pages. The second approach is to use the 1K sector arrangement and just ignore the fact that the last 128 bytes of the last sector aren't written. This also mostly works, but when EBlink reads the last sector (usually when deciding if it needs to be programmed) it will read back the ROM bytes in those last 128 bytes and so it will never match what is in the file to be flashed (forcing the last sector to always be erased and reprogrammed). The best approach, I believe, would be to set up two separate flash areas in the EBlink memory map. The first with 15 1K sectors, and the second with 14 64 byte sectors. This would give the speed of using the sectors for most of the chip, but the granularity on the last sector to avoid the 128 ROM bytes. (This approach would also be helpful looking toward the LPC1700 series of chips, as they have two different flash sections with different sector sizes.) However, it appears that EBlink only uses the first flash section in the memory map when erasing/programming the chip. RE: NXP LPC802 Flashing - embitz - 11-04-2023 You could define your memory asymmetrical I think. So the last sector as a separate block in the XML memory map with different sector size. Can you share your current memory XML? RE: NXP LPC802 Flashing - jdubois - 11-04-2023 I went to copy my XML memory map for you to look at, and found the issue. I wasn't specifying the second flash area starting location correctly. It now works with the two flash areas as it should. One other thing though that I noticed- The LPC802 is strange in that it reports 0x00 instead of 0xFF for an erased flash cell. I thought something was wrong when an erased page returned all zeros, but then I found this in the User Manual: "The blank (erased) state of a page flash memory is a logic 0." This seems to confuses EBlink when it checks to see if the sector is empty. Is there a way to specify all 0's indicates a blank sector rather than all 1's? RE: NXP LPC802 Flashing - embitz - 11-04-2023 Code: // The erased value of these chips is not 0xFF but 0x00 Check also the stm32l1x.script which is also using this option. RE: NXP LPC802 Flashing - jdubois - 11-04-2023 Thanks! I'll post up the scripts here soon. |