• AVR Freaks

Hot!Bootloader in Harmony 3

Author
Luca Pascarella
Junior Member
  • Total Posts : 85
  • Reward points : 0
  • Joined: 2007/05/28 00:53:17
  • Location: The Netherlands
  • Status: offline
2020/02/10 03:18:28 (permalink)
0

Bootloader in Harmony 3

I developed a medium size project for a PIC32MZ with Harmony 3 that has access to the Internet. Now, I need to implement a reliable mechanism to upgrade the firmware or, in other words, I need a bootloader.
 
In my previous projects with Harmony 2, the app was responsible for contacting a remote server, downloading the .hex in an external SPI flash, and calculating the checksum. At the same time, the bootloader checks a trigger and performs the update copying the content of the external flash into PIC32MZ's memory. Actually, the bootloader decodes the .hex file and then erases and writes the PIC32's flash. This solution is not efficient in terms of size because .hex is an ASCII file. Moreover, is no longer present in Harmony 3.
 
In Harmony 3, I saw a change of paradigm in favor of a shrunk .bin file. This solution seems quite good since it reduces the size of the image, but only the UART bootloader is supported at this time.
 
 
Since I have to conclude this project asap, I was wondering what is the best solution for adding a bootloader. Should I grab the Harmony 2 solution in the current project or should I wait for/implement the Harmony 3 solution?
What is your experience with Harmony 3 bootloader? Have you never used it?
#1

5 Replies Related Threads

    Nealet
    New Member
    • Total Posts : 4
    • Reward points : 0
    • Joined: 2019/11/22 02:03:44
    • Location: 0
    • Status: offline
    Re: Bootloader in Harmony 3 2020/02/10 04:06:43 (permalink)
    0
    I did a similar bootloader some time ago. May i suggest the following:
    1. As you download the HEx file from the server, you decode it line by line Verifying the checksum at the end of each line with the contents of the line.
    2. When that is correct for each line parsed, Decode the ASCII format for each 8 bit binary value into binary. Example: the ASCII string value "56" is two Hex values 0x35 and 0x36. Convert that straight to 0x56.
    3. do this for the Record type, No. of bytes, offset address and the received data in a string and save it as such.
    You will be already halving your storage requirement in this step!
    4. If there is an error in the line checksum, flag the error and stop the download there and then.
    Regards
    Nealet
    post edited by Nealet - 2020/02/10 05:22:03
    #2
    Paul PortSol
    Super Member
    • Total Posts : 564
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: Newfoundland, Canada
    • Status: offline
    Re: Bootloader in Harmony 3 2020/02/10 05:42:53 (permalink)
    0
    5. I found it useful to store binary records wrapped with their own index, size, and checksum. The size of the record matching the write size for the target PIC flash memory. That saved effort in the target MCU code, since it FLASHes in chunks.
     
    Paul
     
    #3
    Luca Pascarella
    Junior Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2007/05/28 00:53:17
    • Location: The Netherlands
    • Status: offline
    Re: Bootloader in Harmony 3 2020/02/10 06:14:49 (permalink)
    0
    Thank you all. Interesting suggestions.
     
    I would also add that the bootloader in Harmony 3 specifies xc32-objcopy as a .hex to .bin parser.
    Specifically, they suggest executing the following code after the build is done.
    ${MP_CC_DIR}/xc32-objcopy -I ihex -O binary ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.hex ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.bin

     
    I still have to investigate if the produced .bin is a pure machine code or it saves addresses and checksums.
    Perhaps, one may produce a .bin directly at compile time and perform an overall checksum.  
    #4
    Paul PortSol
    Super Member
    • Total Posts : 564
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: Newfoundland, Canada
    • Status: offline
    Re: Bootloader in Harmony 3 2020/02/10 08:54:58 (permalink)
    0
    Warning:
    The .hex can skip large chunks of unused FLASH.
    If you convert to a full .bin you will always have a maximum size file (OK if you're using most of FLASH).
    If you convert to "binary records at addresses" then you'll likely have a significantly smaller file to transfer, and won't waste time programming unused memory.
    If you already fill your flash - then that won't leave much room for new features.
     
    Paul
    #5
    Luca Pascarella
    Junior Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2007/05/28 00:53:17
    • Location: The Netherlands
    • Status: offline
    Re: Bootloader in Harmony 3 2020/02/11 00:58:12 (permalink)
    0
    Thank you for your suggestions.
     
    I started to investigate the bootloader of Harmony 3. To reduce .bin size, the configuration bits must be removed (also because the bootloader cannot change them). With the original linkage, xc32-objcopy creates a memory block with no holes.
    The following line added to the app linker script removes the config section for PIC32MZ.
    /DISCARD/ : { *(.config_*) }

    In my case, the generated .bin is 1.3MB compared to 3.6MB of the original .hex. I wanna say how expected.
     
    However, the bootloader of Harmony 3 supports only commands from UART but it seems easy enough to add an SPI driver and read bytes from an external flash. I am working on this, I let you know.
     
     
    #6
    Jump to:
    © 2020 APG vNext Commercial Version 4.5