Open swarzynski opened 11 years ago
@swarzynski did you ever restore this issue? This might explain some of the behavior we're seeing.
I've been caught out by this bug in version 1.97. Is this bug still present?
I see the same thing, only it crashes lpc21isp.
It's caused by lpc21isp not coping with files that are not a multiple of the block size.
In NxpDownload here: https://github.com/capiman/lpc21isp/blob/master/lpcprog.c#L1263
There is no check that the access to IspEnvironment->BinaryContent is less than IspEnvironment->BinaryLength so it over reads BinaryContent and you either end up flashing rubbish to the mcu, or crashing as you hit unallocated memory.
I added a check around it:
if ((Pos + Block * 45 + BlockOffset) > IspEnvironment->BinaryLength) {
printf("padding with 0\n");
c = 0;
} else {
c = IspEnvironment->BinaryContent[Pos + Block * 45 + BlockOffset];
}
That pads the last block with 0's. Not a real fix cos verifying still fails as well. But it stops it crashing for me at least.
(This is with an lpc1768)
if ((Pos + Block * 45 + BlockOffset) > IspEnvironment->BinaryLength)
Should that >
be >=
?
Hello!
While programming lpc21isp adds garbage data at the end of program in the flash memory. It is a problem when CRC value is calculated by the code from whole flash memory - CRC will differ when chip will be programmed by in example "Flash Magic" or "lpc21isp". Look at attached picture to see the details. I would be glad if someone try to fix it or point me where to look for the function which is responsible for writing this data.
Regards