Hot!Issues using Unified Bootloader Host with MCC generated bootloader

Author
FabianL
Senior Member
  • Total Posts : 38
  • Reward points : 0
  • Joined: 2017/04/24 05:45:11
  • Location: Germany, Baden-Württemberg
  • Status: offline
2017/04/26 03:36:04 (permalink)
0

Issues using Unified Bootloader Host with MCC generated bootloader

Hello,
 
I'm using pic16f18326 with mcc generated bootloader (new reset vector at 0x300 - all working well) and I'm somewhat struggling with the existing Unified Bootloader Host Application (0.1.3). At some points I found that the commands sent from the Unified Host to my pic contain wrong starting addresses. For example when reaching the checksum request the starting address contains 0x0180 which is half of what I would expect (0x0300) with Bootloader Offset set to 0x300. Though the data length field contains the full 0x3D00 with Program memory specified 0x4000. I'm especially confused about this behavior since others are obviously successfully using the Unífied Host application with their devices. In my case this is always leading to a checksum mismatch. I had to bypass this by shifting the NVMADR in the mcc generated code:
 
// **************************************************************************************
// Calculate Checksum
// In: [<0x08><DataLengthL><DataLengthH> <unused><unused> <ADDRL><ADDRH><ADDRU><unused>...]
// OUT: [9 byte header + ChecksumL + ChecksumH]
uint8_t Calc_Checksum()
{
    NVMADRL = frame.address_L << 1;
    NVMADRH = frame.address_H << 1;
    if(frame.address_L & 0x80)
        NVMADRH += 1;
    NVMCON1 = 0x80;
    check_sum = 0;
    for (uint16_t i = 0;i < frame.data_length; i += 2)
    {
        NVMCON1bits.RD = 1;
        while(NVMCON1bits.RD == 1)
        NOP();
        check_sum += (uint16_t)NVMDAT;
        ++ NVMADR;
     }
     // Bootloader Generator User's Guide suggests to reply with success status in Figure 7-4 but that appears to be a typo.
     //frame.data[0] = COMMAND_SUCCESS;
     frame.data[0] = (uint8_t) (check_sum & 0x00FF);
     frame.data[1] = (uint8_t)((check_sum & 0xFF00) >> 8);
     return (11);
}

 
Might this be a device dependent issue? From the programming specification of the pic16f18326 I found under 3.4 HEX File Usage:
 
"The PIC16(L)F183XX family allows direct addressing for the data EEPROM, so the EEPROM data will appear at address 0xF000 in the hex file."
 
Could this be causing the behavior observed?
 
 
On another matter:
 
I'm planning to integrate a bootloader host into an existing C++ Qt PC application and I wounder if there are libraries dedicated to the hex file parsing necessary and the protocol used by this mcc generated bootloader (I know the unified host uses .jar packages to achive that, but java is kind of out of my expertise)?
Otherwise I was thinking about reusing code from the AN1310 Qt project, adjusting to the new protocol. Does that sound sensible?
 
Any comment or suggestion is highly appreciated.
 
Regards,
Fabian
#1

7 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 15134
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/04/26 09:48:06 (permalink)
    0
    DIfferent PICs have the EEPROM at different addresses.  And Old ones can not use the FLASH API to write the EEPROM.
     
    Parsing an "Intel Hex" File is not that hard.  Goggle the format.
    #2
    FabianL
    Senior Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/04/24 05:45:11
    • Location: Germany, Baden-Württemberg
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/04/27 02:00:41 (permalink)
    0
    Thank your for your reply NKurzman.
     
    I'm not sure what part of my post you're referring to about the EEPROM addresses. If it is the quote from the programming specification, I was maybe taking that out of it's context a little, this is the full text:
     
    In the hex file there are two bytes per program word stored in the Intel® INHX32 hex format. Data is stored LSB first, MSB second. Because there are two bytes per word, the addresses in the hex file are 2x the address in program memory. For example, if the Configuration Word 1 is stored at 8007h, in the hex file this will be referenced as 1000Eh-1000Fh. The PIC16(L)F183XX family allows direct addressing for the data EEPROM, so the EEPROM data will appear at address 0xF000 in the hex file.

     
    The reason I posted that was because I was thinking the PIC16(L)F183XX may be different from older chips regarding the address reference. Maybe leading to the Unified Host halve something it shouldn't?
     
    Thanks
    Fabian
    #3
    FabianL
    Senior Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/04/24 05:45:11
    • Location: Germany, Baden-Württemberg
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/04/27 05:58:01 (permalink)
    0
    I was able to resolve the issue regarding the funny serial data streams between the Unified Host Application and the generated bootloader by applying the solution from the following thread (multiplying by 2 the bootloader offset and program memory size):
    https://www.microchip.com/forums/m960192.aspx
     
    Of course I then also had to unmake my changes to the Calc_Checksum() function.
     
    Will now be working on implementing the host side protocol in c++.
    post edited by FabianL - 2017/04/27 05:59:04
    #4
    Danno
    Super Member
    • Total Posts : 165
    • Reward points : 0
    • Joined: 2005/09/07 10:12:10
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/05/02 17:05:46 (permalink)
    5 (1)
    I trust you found the revised User's guide at http://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en573289  DS40001779B.  It has a much better description of the protocol than the original.
     
    #5
    FabianL
    Senior Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/04/24 05:45:11
    • Location: Germany, Baden-Württemberg
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/05/12 03:10:04 (permalink)
    0
    Yes thanks Danno. This is the only User's Guide I could find on the microchip pages regarding that bootloader and protocol.
     
    I 'finished' modifying the AN1310 bootloader Qt project's code according to my requirements by basically changing everything grin: grin.
    Probably only working for pic16f devices as I didn't really bother to take care about anything other for now. I used the command line implementation, moved it to another thread from my main application and use signals/slots to pass the arguments and retrieve status information.
     
    If anyone is interested in doing something similar: No changes needed for the hex parsing. Check for the CRC computation as AN1310 does that differently.
    The really nice thing is the sql database holding all the necessary device information.
     
    Regards
    Fabian
    #6
    PIC16F1788
    New Member
    • Total Posts : 17
    • Reward points : 0
    • Joined: 2017/10/24 05:09:31
    • Location: 0
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/12/06 09:06:39 (permalink)
    0
    Hi Fabian! Hope you doing great. I am also planning to implement the bootloader host program into my microcontroller. Luckily i found out that you are also working on PIC16F and have developed one host program which works for PIC16F. It will be really nice of you if you can share its source code.
     
    Thanks in advance,
     
    FabianL
    Yes thanks Danno. This is the only User's Guide I could find on the microchip pages regarding that bootloader and protocol.
     
    I 'finished' modifying the AN1310 bootloader Qt project's code according to my requirements by basically changing everything grin: grin.
    Probably only working for pic16f devices as I didn't really bother to take care about anything other for now. I used the command line implementation, moved it to another thread from my main application and use signals/slots to pass the arguments and retrieve status information.
     
    If anyone is interested in doing something similar: No changes needed for the hex parsing. Check for the CRC computation as AN1310 does that differently.
    The really nice thing is the sql database holding all the necessary device information.
     
    Regards
    Fabian




    #7
    FabianL
    Senior Member
    • Total Posts : 38
    • Reward points : 0
    • Joined: 2017/04/24 05:45:11
    • Location: Germany, Baden-Württemberg
    • Status: offline
    Re: Issues using Unified Bootloader Host with MCC generated bootloader 2017/12/07 02:18:43 (permalink)
    0
    Hi PIC16F1788 LoL: LoL,
     
    It's been a while that I have been working on that but I will be glad to help if I can.
     
    Of which source code are you particularly talking about? The bootloader code on the PIC itself or the code for the host application? The latter is derived from the AN1310 Bootloader Qt Project which you find here:
    https://github.com/bcabebe/Serial-Bootloader-AN1310-v1.05/tree/master/PC%20Software
     
    I used the cl (command line) version in order to control the bootloader from my main program while the bootloader itself runs in a different thread, thus repetitively starting the bootloader with different textual commands in order to be able to achieve what I wanted.
     
    I have made major changes to most of the source code for it to work with the MCC generated bootloader code (works for me using PIC16F18326). But I never do a great job at documenting. There are a lot of TODO's in the code. For example I hard implemented the bootloaders start and end addresses since they wont change for me.
     
    If you still want to see if that is of help for you, I can send you the code. Just send me a PM with your email.
     
    Regards
    Fabian
    #8
    Jump to:
    © 2017 APG vNext Commercial Version 4.5