Here are my scripts for supporting the LPC line of chips. They seem to be working ok, but I can't guarantee they're perfect as they haven't seen a huge ton of testing. I've tested them on an LPC802, LPC1115, and LPC1769. Other chips in those three lines should work as well, but most of them will need their IDs added to the device lookup functions. I did not update the main auto.script to check for LPC devices, as I suspect the ID check would upset non-LPC chips. I've got an idea for a less invasive check, but haven't implemented it yet.
Question about the lpc800 flash script. Is the clearing of the remaining bytes to 0x00 still necessary when you specified the flash erase value on device level?
Code:
// Fill up any remaining bytes in the block with 0x00
for (local i=buffer.getSize()/4*4;i<writeSize;i+=4) {
_n_throw(intrfApi.writeMem32(DATA_ADDR+i, 0x0))
}
The above code is just making sure that if the data passed to my script in the buffer is not an even multiple of a Flash programming block size, that the rest of the RAM being to send to the Flash is filled with empty bytes rather than whatever happened to be in RAM (usually the remains of the last data block sent).
In other words, if I'm asked to program 32 bytes to flash, I cannot do that. I can only write 64 bytes at a minimum. So I send 32 bytes of data and 32 bytes of 0.
17-04-2023, 08:17 AM (This post was last modified: 17-04-2023, 08:22 AM by embitz.)
If that's the purpose then we can skip it. The length of the buffer is always equal to the length of the changes in the sector. If the sector is just half filled then EBlink will skip all trailing 0x00 (the erase value set by the device API) because it's already cleared by the sector erase.
Sometimes a MCU needs a full sector size to program and with the
Code:
DeviceApi::setFlashDontTrim()
option we can disable the sector trimming. But even then a sector will never be written with some lefts over of buffers. On sector erase the internal sector cache is reset to the earseValue and the content of the sector cache is passed by the EBuffer.
17-04-2023, 03:15 PM (This post was last modified: 17-04-2023, 03:17 PM by jdubois.)
No, I still think we need to leave that code in. It's a peculiarity with the NXP flash process, rather than how EBlink handles the buffer.
If I have a file to flash that is 1032 bytes long, that will be one full flash sector of 1024 bytes and only the first 8 bytes of the second sector. Flashing the first sector is no issue. Flashing the second sector is a problem. The flash routines on the chip cannot flash only 8 bytes. I'm forced to flash at least 64 bytes at a time. So I have to flash 8 bytes of data and 56 bytes of blank. If I do not include the above code that fills the on chip RAM buffer with those 56 blank bytes, it will program whatever is in the RAM at the time of the call to the flash routine. That is a failure state.
