11-04-2023, 02:22 PM
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.
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.
