struct.error: unpack requires a buffer of 14 bytes

[mSavardCatalys]

MCU: dsPIC33CH256MP508 mcbootflash version: 6.0.0 Following this issue: https://github.com/bessman/mcbootflash/issues/9 Hi bessman, we are still not able to properly flash a dsPIC33CH256MP508 with MCC bootloader. Downloading using mcbootflash generate errors this time. We are able to flash it properly using Microchip Unified Bootloader Host Application v1.19.1 though. Here are the files you previously ask my collegue. Note that "mcbootflash.txt" and "Unified Bootloader Host Application (UBHA).txt" were read using MPLAB and SNAP debugger.

Do not mind asking for further clarification or debug data!

output.txt app_to_be_programmed.txt Unified Bootloader Host Application (UBHA).txt mcbootflash.txt

[bessman]

Interesting! I think this is actually a bug in the bootloader itself.

The problem is that your firmware goes right up to the upper boundary of the program memory range. After every write to flash, mcbootflash checks that the write is OK by comparing a locally calculated checksum with a remote ditto. However, when checking whether the requested checksum in the legal range, the bootloader uses the data length in bytes to determine the final address of the checksum. This is incorrect, because the checksum is actually calculated over 16-bit words, not bytes.

I can only assume UBHA either works around this, or just doesn't check the checksum after write.

A viable workaround should be to skip the final one or two checksums if the data borders the upper legal range.

[bessman]

Give v6.1.0 a try. I think it should fix your issue. Let me know how it goes :smile:

[mSavardCatalys]

I am currently using version 7.0.2 and I still have an error. The problemed seems to come when verifying the integrity of the written app. output.txt mcbootflash.txt

[bessman]

Thanks for reporting back! I've split this into a new issue, since your current problem is not the same bug as the one you originally reported.

It is possible it is still two separate bugs; I'm surprised the bootloader says VERIFY_FAIL after the flashing operation is complete. In #9, your colleague @aBarilCatalys reported that mcbootflash finished without error but the flashed application was non-functional; given that result, I would not have expected the bootloader to complain at this point. (Though I am glad it did, as the bug with the final four bytes not being written may not have been detected otherwise)

I will make it so the final bytes are also written; if at that point the bootloader still does not self verify correctly we will open a new issue for that.