• AVR Freaks

Hot!PIC18F25Q10 Bootloader Issues

Author
zehcorah
New Member
  • Total Posts : 6
  • Reward points : 0
  • Joined: 2019/10/30 08:11:47
  • Location: Canada, Ontario
  • Status: online
2019/11/15 07:16:41 (permalink)
0

PIC18F25Q10 Bootloader Issues

Hello All,
 
Currently, I am working on implementing the functionality of a bootloader on my PIC18F25Q10.  I am running MP Lab X v5.25, XC V2.10, curiosity HPC PKoB and MCC v3.0.  I have done some digging about online to find resources, and I assumed that the information in the bootloader generator User Guide (found here https://www.microchip.com/promo/8-bit-bootloader) would be sufficient enough to get started with the pre generated microchip code but i have run into a few snags.  
 
Issue 1) when attempting to combine the bootloader on my no configuration setting, with a simple blinky application, I get error (944) data conflict at address 300000h (my configuration bits)  i set up an if defined to take out the config bits in device_config.c generated by mcc.  I read that the two files will merge happily if the config bits match, which works, but wont be a good long term solution.  I must be missing something here.  
 
Issue 2) With the bootloader running on the target, I used a TTL-232 3v3 usb->serial converter to establish serial communication with the target device.  The device shows properly in my devices at COM 5, so i set up the Unified Bootloader Host App to use com 5 at 9600 Baud.  I am however confused about the Bootloader Offset address.  for PIC18's it defaults to 0x300.  my boot application is in memory locations 0x0-0x7FF (the boot sector of my device).  What should this be set to?  My first guess would be the remapped reset vector of my bootloader, which i put at 0x800 (the start of the user program memory).  
 
Issue 3) More just inexperienced confusion on my part for this one, but what hex file should I be loading into the Unified bootloader application.  I have tried the Bootloader w/ config, the offset blinky app (to 0x800) and the combined blinky app (boot loader in 0x0-0x7ff and app offset to 0x800).  The results are as follows(all with the bootloader running on target):
Bootloader hex:
Bootloader offset at 0x800: Failure Hint: Confirm Hex Offset, propably because the app is limited to 0x0-0x7ff.
Bootloader offset at 0x000: gets to the point where it resets the board, but then the device fails to respond.  The device gets stuck polling the autobaud loop looking for a command.  
 
Offset blinky app hex: 
Bootloader offset at 0x800: Device fails to respond to the Checksum command
Bootloader offset at 0x000: Same as above
 
Combined blinky app hex: 
Had same results as the offset app.
 
Hopefully i have provided the necessary information for my problems.  Any help is appreciated!
 
Thanks,
 
Ryan
#1

7 Replies Related Threads

    zehcorah
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/10/30 08:11:47
    • Location: Canada, Ontario
    • Status: online
    Re: PIC18F25Q10 Bootloader Issues 2019/11/19 07:23:18 (permalink)
    0
    Small Update,
     
    I did some experimenting yesterday and found a few things.  The most major was that the Flash routines generated for my PIC device did not work in the slightest.  It all looked very strange but a simple test program of writing and reading using their method confirmed my suspicions.  To fix this I wrote a new flash write function following section 11.1.4.2 of the PIC18F25Q10 datasheet, i also included simple verification for each word written.  
     
    In addition to the write, all the flash routines use the wrong unlock keys, for some reason the Unified Bootloader Application only sends 0x55 and 0xAA as the keys for all commands using the NVM registers, when they are different for each command.  I went through and hard coded them to the correct values.
     
    Knowing this the earlier behavior is explainable.  When i would send a copy of the already loaded code, i would see it succeed the checksum, this is because the erase function and write function were wrong, so there was no change to the code and the checksum would be correct.  Everything else would fail because the flash memory never changed.
     
    Now that i have the code verified, I am wondering if the Unified Bootloader Application works with the generated code effectively, it appears to send only one write command (64 words) then perform a checksum immediately after.  This checksum always fails.  It appears to expect the complete checksum for the file loaded, this is verified by the earlier behavior I observed.
     
    The New Write Function
     
    uint8_t Write_Flash2()
    {
        uint8_t GIEBitValue = INTCONbits.GIE;
        uint8_t checkH = 0;
        uint8_t checkL = 0;
        NVMCON0bits.NVMEN = 1;
        
        NVMADRL = frame.address_L;
        NVMADRH = frame.address_H;
        NVMADRU = frame.address_U; //LOADS PFM ADDRESS TO THE NVM REGISTER
        
        INTCONbits.GIE = 0;
        
        if (NVMADR < NEW_RESET_VECTOR)
        { //CHECKS IF THE DESIRED ADDRESS IS BELOW THE BOUNDS OF OUR USER PROGRAM SPACE 
            frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
            return (10); 
        }
        for (int i = 0; i < frame.data_length; i+=2)
        {
            NVMDATH = frame.data[i+1];
            NVMDATL = frame.data[i]; //FILLS THE NVMDAT REGISTER WITH THE DESIRED WORD
            
            if (NVMADR >= END_FLASH)
            { //CHECKS IF THE DESIRED ADDRESS HAS GONE ABOVE THE BOUNDS OF OUR USER PROGRAM SPACE
                frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
                return (10);
            }
            
            NVMCON2 = 0x55;
            NVMCON2 = 0xAA; //WORD WRITE UNLOCK SEQUENCE
            
            NVMCON1bits.WR = 1;
            while(NVMCON1bits.WR==1){} //SPIN DELAY FOR PFM WRITE
            
            
            NVMCON1bits.RD =1;
            while(NVMCON1bits.RD==1){} //SPIN DELAY FOR PFM READ
            checkH = NVMDATH;
            
            
            NVMCON1bits.RD =1;
            while(NVMCON1bits.RD==1){} //SPIN DELAY FOR PFM READ
            checkL = NVMDATL;
            
            
            if(checkL!=frame.data[i] || checkH !=frame.data[i+1])
            {
                frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
                Nuke_User_Flash();
                return (10); //UNDERSTOOD AS A FAILED COMMAND BY THE UBL APPLICATION
            }
            NVMADR += 2;
            
        }
        if(NVMCON0bits.NVMERR)
        {
            frame.data[0] = ERROR_ADDRESS_OUT_OF_RANGE;
            return (10); //UNDERSTOOD AS A FAILED COMMAND BY THE UBL APPLICATION
        }
        frame.data[0] = COMMAND_SUCCESS;
        EE_Key_1 = 0x00; // erase EE Keys
        EE_Key_2 = 0x00;
        
        NVMCON0bits.NVMEN = 0;
        INTCONbits.GIE = GIEBitValue;
                
        return (10);
    }

     
     
    uint8_t Nuke_User_Flash()
    {
        NVMADRL = 0x00;
        NVMADRH = 0x10;
        NVMADRU = 0x00;
        
        for (uint16_t i=0; i < 0xE0; i++)
        {
            if (NVMADR >= END_FLASH)
            {
                return 10;
            }
                  // Setup writes
            NVMCON2 = 0xCC;
            NVMCON2 = 0x33;
            NVMCON1bits.SECER = 1; // Start the erase
            while(NVMCON1bits.SECER){}
            
            
            NVMADR += ERASE_FLASH_BLOCKSIZE;
            return 0;
        }
    }

     
    Any thoughts?
     
     
    #2
    mbrowning
    USNA79
    • Total Posts : 1564
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: PIC18F25Q10 Bootloader Issues 2019/11/19 07:46:18 (permalink)
    +1 (1)
    Unified Bootloader Application only sends 0x55 and 0xAA as the keys for all commands using the NVM registers, when they are different for each command.
    This is a change from all previous 8b PICs that I'm aware of. I'm not sure if the bootloader java has been updated recently, but it didn't support 128KByte PICs for a long time, so this update will probably take awhile.
     
    I would suggest submitting a support ticket so your findings get on the queue for getting fixed. No guarantees any Microchip employees will ever see or take action on user forum posts.

    Go Navy! Beat Army!
    #3
    zehcorah
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/10/30 08:11:47
    • Location: Canada, Ontario
    • Status: online
    Re: PIC18F25Q10 Bootloader Issues 2019/11/19 07:57:29 (permalink)
    0
    Hey mbrowning,
     
    mbrowning
    This is a change from all previous 8b PICs that I'm aware of. I'm not sure if the bootloader java has been updated recently, but it didn't support 128KByte PICs for a long time, so this update will probably take awhile.

     
    I sort of figured as much but the confirmation is nice. 
     
    Any idea why the checksum behavior i mentioned would be happening?  I manually change the NVMCON2 values so the java application sending incorrect unlock keys shouldn't be the cause.  Maybe just another case of new hardware old software?
     
    Thanks,
     
    Ryan
    #4
    mbrowning
    USNA79
    • Total Posts : 1564
    • Reward points : 0
    • Joined: 2005/03/16 14:32:56
    • Location: Melbourne, FL
    • Status: offline
    Re: PIC18F25Q10 Bootloader Issues 2019/11/19 08:03:33 (permalink)
    0
    Sorry, haven't used that device and I only briefly used bootloader app 1.18 (which was only up for a short time before it was replaced with 1.14). I guess it's up to 1.15 which I think adds the 128K support. I very quickly wrote my own C# bootloader and changed the protocol a bit to add some features. And that was 2 years ago so I barely remember what I did then.

    Go Navy! Beat Army!
    #5
    zehcorah
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/10/30 08:11:47
    • Location: Canada, Ontario
    • Status: online
    Re: PIC18F25Q10 Bootloader Issues 2019/11/19 08:29:58 (permalink)
    0
    All good, Might be the route I will need to take depending on what some more researching turns up.  Thanks for the help.
     
    Ryan
    #6
    Danno
    Super Member
    • Total Posts : 273
    • Reward points : 0
    • Joined: 2005/09/07 10:12:10
    • Status: offline
    Re: PIC18F25Q10 Bootloader Issues 2019/11/20 12:37:42 (permalink)
    0
    the > 64KB problem has been resolved.  However the Q10 as I understand it has a different memory access scheme.  That part would likely need to be modified.  But the rest should work as is.
     
    $.02
    #7
    zehcorah
    New Member
    • Total Posts : 6
    • Reward points : 0
    • Joined: 2019/10/30 08:11:47
    • Location: Canada, Ontario
    • Status: online
    Re: PIC18F25Q10 Bootloader Issues 2019/11/21 05:00:24 (permalink)
    0
    Hi Danno,
     
    It should, says all PIC18s are compatible.  But maybe it doesn't do the advanced micro-controller line?  I wasn't able to get the issues with the Unified Bootloader working, but verified the new code i wrote with Real Term, sending the commands manually.  Took some more edits but got all those working properly, I will be writing my own bootloader application as mbrowning mentioned. 
     
    I doubt the unified bootloader is intended to be a very long term or robust solution by any definition, rather just a platform to verify the functionality of a bootloader.  That being said, I might as well make one that is designed to fit my situation.
     
    Thanks,
     
    Ryan
    #8
    Jump to:
    © 2019 APG vNext Commercial Version 4.5