Compatibility issue with PIC16F15356 and how I fixed it #4
Description
Hello,
after several days of searching how to use the autogenerated MCC bootloader code for upgrading the firmware of my PIC and finding out that the ancient Java "Unified Bootloader Host Application" from Microchip can only be used from the GUI and not from the command line, I've found your post on the forum and I've tried using this GO implementation.
I'm just starting to program a PIC for the first time so I'm learning while I try and I'm not 100% sure of what I'm saying, but I wanted to show you what I did to this program to make it works so maybe you can comprehend and explain what the problem is.
After some investigation into what parameter to set for my PIC in the "profile.yaml" I've got these:
profile:
bootloaderoffset: 0xC00
flashsize: 0x8000
eepromoffset: 0x1E000
eepromsize: 0
configoffset: 0x1000E
configsize: 0x0A
idoffset: 0x10000
idsize: 8
options:
programeeprom: false
programconfig: false
programid: false
verifybyreading: false
1° problem: I had to put "idoffset" to 0x10000 because in my .HEX file there is a record with extended 32-bit linear address to that address and even if "programid" is false the parsing of the HEX file was returning "invalid data segment at address 0x10000".
Maybe the hex parsing should not check for the correct address range if the relative setting is false?
2° problem: The PIC is in word and the real address for bootloaderoffset and flashsize is 0x600/0x4000 respectively, but the HEX has the values in bytes so like in the Java version I had to put 0xC00/0x8000. With these values, the HEX parsing was working but not the erase/write of the flash. Comparing the "packets" sent by this implementation and the Java implementation (using a "serial port sniffer"), a /2 is missing to transform from bytes to words. Here you can see the same packet which is written at address 0x0620 by the Java implementation (left) and at 0x0C40 by your GO implementation (right)
To fix this I've changed the bootloader.go file to use the given address / 2.
3° problem: With the previous change the packets were now using the same address and the erase/write flash portion was working, but then the CRC computation would not find the correct value and gives an error.
By looking again at the "serial packets" comparison between Java and Go implementations you can see that not only the address was different but also the length of the packet, 0x40 for Java and 0x20 for Go.
This number is set by using the response of the pick to the first "Get Version" command (and in my case is 0x20), but for some reason, the Java implementation then doubles the number to 0x40.
By doing the same and doubling the number returned by the PIC in the ParseGetVersionResponse function of "bootloader.go" file, finally, the generated command that writes the PIC's flash is the same for both the Java and Go implementations and also the computed/read CRCs are the same and the update finishes correctly.
4° problem?/difference: With the previous changes (*2 to the length and /2 to the address) the firmware upgrade using the Go implementations seems to work correctly, but there is still one difference between the Java implementation on the erase flash.
Java is erasing from address 0x0600 with a length of 0x01D0, instead, the Go implementation is doing 2 erase the first from 0x0600 with a length of 0x0010 and a second one from 0x0C40 with a length of 0x001E.
The one from your implementation is computed from the addresses read from the HEX file so they seem correct, I don't know how and why the Java implementation erases all that memory.
This difference doesn't seem to affect the upgrade, but I don't know enough about the PIC architecture to know if it could be a problem in some cases.
Finally, I wanted to thank you for this implementation, I can't believe there is no other "official" way to use the bootloader autogenerated by MCC if not by using the really old Java implementation from GUI.
I hope these informations can help you and if you have any question/test you want me to do I'm available.
Have a good day,
Matteo.