+- 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: Scripts to support NXP LPC chips (/thread-162.html)
Pages:
1
2
Scripts to support NXP LPC chips - jdubois - 12-04-2023
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.
RE: Scripts to support NXP LPC chips - embitz - 12-04-2023
Many thanks for sharing!
That was the whole idea behind using a script engine for the device related functions.
Awesome! I will add them to the install package.
RE: Scripts to support NXP LPC chips - jdubois - 12-04-2023
Happy to contribute. Embitz and EBlink have been so useful to me, the least I can do is give a little back!
RE: Scripts to support NXP LPC chips - embitz - 13-04-2023
Hi,
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))
}RE: Scripts to support NXP LPC chips - jdubois - 16-04-2023
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.
RE: Scripts to support NXP LPC chips - embitz - 17-04-2023
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()RE: Scripts to support NXP LPC chips - embitz - 17-04-2023
I updated the scripts on github
https://github.com/EmBitz/EBlink-scripts
RE: Scripts to support NXP LPC chips - jdubois - 17-04-2023
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.
RE: Scripts to support NXP LPC chips - embitz - 17-04-2023
Ah, ok.
I will revert.
RE: Scripts to support NXP LPC chips - jdubois - 18-04-2023
No worries. I'm glad you looked the scripts over rather than just stuffing them in without a thought!