Missing a small portion of the non-contiguous .hex file on dsPIC33CH256MP508

[aBarilCatalys]

Using mcbootflash version 5.1.1 I am not able to properly flash a dsPIC33CH256MP508 with MCC bootloader. Downloading using mcbootflash doesn't generate any error but the program is not functionnal.
I am able to flash it properly using Microchip Unified Bootloader Host Application v1.19.1. The program works.

Using MPLAB and SNAP debugger, I was able to read back the downloaded .hex file with both programs but mcbootflash missed a section at the end of the program. I suspect this missing section explains why the program doesn't work with mcbootflash. The hex file I want to download is not contiguous. I have attached both the Java application downloaded hex and the mcbootflash downloaded hex so you can see the difference if you diff those two files.
I suspect this a is problem with the initial hex file parsing of mcbootflash but I may be wrong too...

If you need further clarification or debug data I would be happy to provide it!
Thank you and good luck.
python_mcbootflash_read.txt
java_unified_bootloader_read.txt

[mathieugalle]

Le mer. 6 sept. 2023 à 23:01, aBarilCatalys ***@***.***> a écrit :

…

Using mcbootflash version 5.1.1 I am not able to properly flash a dsPIC33CH256MP508 with MCC bootloader. Downloading using mcbootflash doesn't generate any error but the program is not functionnal. I am able to flash it properly using Microchip Unified Bootloader Host Application v1.19.1. The program works. Using MPLAB and SNAP debugger, I was able to read back the downloaded .hex file with both programs but mcbootflash missed a section at the end of the program. I suspect this missing section explains why the program doesn't work with mcbootflash. The hex file I want to download is not contiguous. I have attached both the Java application downloaded hex and the mcbootflash downloaded hex so you can see the difference. I suspect this a is problem with the initial hex file parsing of mcbootflash but I may be wrong too... If you need further clarification or debug data I would be happy to provide it! Thank you and good luck. python_mcbootflash_read.txt <https://github.com/bessman/mcbootflash/files/12542495/python_mcbootflash_read.txt> java_unified_bootloader_read.txt <https://github.com/bessman/mcbootflash/files/12542496/java_unified_bootloader_read.txt> — Reply to this email directly, view it on GitHub <#9>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACGEHWWW3QPQFTLWWBVCIV3XZDQCZANCNFSM6AAAAAA4N5I2MI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[bessman]

You are most likely right that the problem is due to the file being non-continuous. I hadn't considered that possibility, so it's probably not handled correctly.

Thanks for the readbacks, I'll take a look and try to fix it.

[bessman]

Could you also share the hex-file itself, i.e. the file you gave to mcbootflash to flash to your MCU?

It would also be useful to have the output of mcbootflash run with the --verbose flag active. The output will be large, so you should redirect it to a logfile.

[bessman]

Looking at the code, it looks like this should work already. As long as all segments are fully within the writable memory area as reported by MCC, it shouldn't matter whether they are contiguous.

At present, my guess as to what is happening is that mcbootflash thinks the missing segment does not fit within the program memory range. That could mean one of a few things:

1. mcbootflash subtly miscalculates the segment's space requirements, incorrectly surmising that it does not fit when in fact it does. Possible off-by-one error somewhere?
2. The segment does in fact not fit in the program memory, but should be flashed anyway. Not sure how to handle that, would need to try and figure out what UBHA is doing differently.

A verbose output from mcbootflash should shed some light on the situation.

[aBarilCatalys]

Hello M. Bessman,
First of all, thank you for taking the time to look at this issue so quickly.
Here is the .hex file that I want to program, sorry for leaving it out in my first post:
app_to_be_programmed .txt
Here is the verbose output. I am not able to fully understand it, but it looks like everything is correct?
output.txt

The dsPIC33CH seems to have a unique memory scheme with the master and slave cores. If you take a look at figure 1.1 of the dsPIC33CH data sheet (https://ww1.microchip.com/downloads/aemDocuments/documents/MCU16/ProductDocuments/DataSheets/dsPIC33CH512MP508-Family-Data-Sheet-DS70005371D.pdf) you will see that the slave core program is included in the flash memory (hex file) after the end of the master core program. The linker script that MCC generates seems to put the slave program at the end of the memory creating the gap in the hex.file and making it non-contiguous.

[bessman]

I've looked over the hexfile and the missing data is part of a segment which just barely does not fit within the program memory range, by just three bytes. Therefore, mcbootflash ignores it.

At some point during development, I decided to not flash contiguous data segments unless the whole segment fit. I can't recall why I did that. Thinking about it now, it seems wrong. Any data within the program memory range should be flashed. I can't see any downside; at worst any additional data would just be unreachable from the rest of the program.

I've made a prerelease, v5.1.2b1, which should fix your problem. You can install it from here or from pypi with pip install --pre -U mcbootflash. Let me know if it works and I'll promote it to a proper release.

[bessman]

Since I'm pretty sure the new behavior is correct, I've included it in the recent v6.0.0 release. I'm tentatively closing this as fixed; let me know if the problem persist. If it is indeed fixed, I would appreciate a confirmation 😄