• AVR Freaks

Hot!Microchip bootloader for PIC32MK MC

Author
MPaulHolmes
Junior Member
  • Total Posts : 89
  • Reward points : 0
  • Joined: 2009/10/31 10:52:40
  • Location: 0
  • Status: offline
2020/06/01 21:58:53 (permalink)
0

Microchip bootloader for PIC32MK MC

I downloaded the bootloader here:
https://github.com/Microchip-MPLAB-Harmony/bootloader
And I think I got it ported over to my own board.  So, I made a new project for the pic32mk1024mcf100, and made a few changes  with all of the #pragma stuff at the beginning, just using the defaults for what I usually use.
 
Then, I got the python code running:
python btl_host.py -i COM11 -d PIC32MK -f vcu.hex -a 0x1d002fff -v
 
Then it just says 
Unlocking...
Warning: no response received, retrying 1
...
 
One question I have is, the address for the bootloader I guess is 0x1d000000 to 0x1d001fff, I don't know what to put in for the -a address.  Does anybody have any suggestions as to what I could do to get this working?  This is one reason I hate using code that I didn't write.
#1

11 Replies Related Threads

    optimus_jack
    Senior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2017/02/16 03:02:47
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/01 22:44:14 (permalink)
    5 (1)
    Hi,
    1. You should be giving the start address of the Application image. (0x9D000000) unless you have given a different start address while building your application project.
    https://microchip-mplab-harmony.github.io/bootloader/00090.html
     
    2. The UART bootloader expects a binary file, i see you are providing the hex file as an input. Below is the step to generate binary using MPLABX. Check the Image (Build Settings for generating Binary) from below link
    ${MP_CC_DIR}/xc32-objcopy -I ihex -O binary ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.hex ${DISTDIR}/${PROJECTNAME}.${IMAGE_TYPE}.bin
    https://microchip-mplab-h.../bootloader/00063.html
    #2
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/03 13:36:33 (permalink)
    0
    Has anyone successfully gotten this project to run on the pic32mk1024mfc100?  It seems that I have gone through all of the directions that they have, and it still does this:
    python btl_host.py -i COM11 -d PIC32MK -f TheirSampleApplication.bin -a 0x9d000000 -v
     
    Then it just says 
    Unlocking...
    Warning: no response received, retrying 1
    ...

    What I do is, open the bootloader (not failsafe) UART project in MPLab, change all of the UART6 stuff to UART1 since that's what I'm using, then change the toggle switch to the pin that I'm using for an external switch.
    Then, I go up to 
    Production -> Set Project configuration -> Customize 
    then select the pic32mk1024mfc100 as the device, and select pickit 3 as the programmer.
     
    Then, I program the bootloader onto the microcontroller successfully.  It runs, but is not receiving any data from the python program when I type "python btl_host.py -i COM11 -d PIC32MK -f dummyProgram.bin -a 0x9d000000 -v"
     
    If I screw something up when I compile their sample application, will the python program not even try to send any of the data over?
     
     
    #3
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/03 17:20:18 (permalink)
    0
    Does anybody know if you can use the linker script for the pic32mk1024GPE100 for the test app if I am using a pic32mk1024mfc100?
    #4
    optimus_jack
    Senior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2017/02/16 03:02:47
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/03 20:32:40 (permalink)
    0
    Hi,
    1. If you are using the existing UART bootloader project for PIC32MK1024GPE100 then, Before launching  MHC for the bootloader project make sure you change the device in the project properties first and then launch MHC. If you have already done then that is fine.
    2. In order to test if your configurations are proper with respect to UART1, You can modify the below main.c of your bootloader code to receive a byte and echo it back over a Terminal program like Tera Term.
     
    int main ( void )
    {
        /* Initialize all modules */
        SYS_Initialize ( NULL );

        while (1)
        {
            if (UART1_ReceiverIsReady() == true)
            {
                UART1_WriteByte(UART1_ReadByte());
            }
        }

        bootloader_Start();

        /* Execution should not come here during normal operation */
        return ( EXIT_FAILURE );
    }
     
    3. Yes you can use the test_app linker script of GPE100 to MCF100 as they belong to same family.
    #5
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 10:48:55 (permalink)
    5 (1)
    I forgot to set the ansel bit to 0 on one of the UART pins (also, their use of the FRC didn't let the UART work I guess, so I switched over to using the external crystal at startup). So, now it at least sends data. However, My next question (because of course it still doesn't work!  haha):  Next, I try to load the .BIN file for the test app, and this happens:
    python btl_host.py -v -a 0x9d000000 -i COM11 -f testApp.bin -d PIC32MK
    Unlocking
    Error: invalid response code (0x51). Check that your file size and address are correct.
     
    Is the 0x9d000000 OK?  Does it have to be some other format for python to accept it?  What do they mean "file size" is correct?  I didn't state the file size anywhere, so how could I be wrong about it?
     
    EDIT:  It worked after leaving the power to my board on, and doing this (4th times the charm!):
    python btl_host.py -v -a 0x9d000000 -i COM11 -f testApp.bin -d PIC32MK
    python btl_host.py -v -a 0x9d000000 -i COM11 -f testApp.bin -d PIC32MK
    python btl_host.py -v -a 0x9d000000 -i COM11 -f testApp.bin -d PIC32MK
    python btl_host.py -v -a 0x9d000000 -i COM11 -f testApp.bin -d PIC32MK
     
    The first few said it was an invalid response code.  Then it was successful.  Has anyone seen that behavior?
     It is consistent too.  Always on the 4th try.  Then, it works every time after that.  So:
    nope, nope, nope, yep, yep, yep, yep, ...
    post edited by MPaulHolmes - 2020/06/04 18:57:27
    #6
    optimus_jack
    Senior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2017/02/16 03:02:47
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 19:05:52 (permalink)
    0
    Hi,
    If we see the unlock command code in bootloader, it validates the incoming address and the size of the binary being received. Size of the binary is calculated by the python file.
     
    I have not see this behavior on my PIC32MK devices (GPE, MCJ, MCM). May be once you program the bootloader from MPLABX, try to disconnect and connect the UART cable and then send the  command.
    #7
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 21:43:37 (permalink)
    0
    Interesting, So, the BL_GUARD thing is:
    byte 0:  4D
    byte 1: 43
    byte 2: 48
    byte 3: 50
     
    But the first 4 bytes that are received by the bootloader go like this:
    TRY #1:
    0
    0
    0
    4D
     
    TRY #2:
    0
    0
    4D
    43
     
    TRY #3:
    0
    4D
    43
    48
     
    TRY #4:
    4D
    43
    48
    50
    HURRAY!  SUCCESS FINALLY!
    #8
    optimus_jack
    Senior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2017/02/16 03:02:47
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 21:59:10 (permalink)
    0
    Interesting :)

    Did you try to probe the UART lines and check if Data on the line itself is as per above tries or its the bootloader code which is discarding the bytes.
    #9
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 22:13:45 (permalink)
    0
    I've never probed UART lines before.  Like, with an oscilloscope?  Hmm, I could try that. 
    #10
    optimus_jack
    Senior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2017/02/16 03:02:47
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/04 22:18:26 (permalink)
    0
    Yes with an oscilloscope or a logic analyzer.
    #11
    MPaulHolmes
    Junior Member
    • Total Posts : 89
    • Reward points : 0
    • Joined: 2009/10/31 10:52:40
    • Location: 0
    • Status: offline
    Re: Microchip bootloader for PIC32MK MC 2020/06/06 10:22:57 (permalink)
    0
    Well, I just did a modification to the software to ignore the 0's and it seems to work.  Here's my next question:
    If I wanted to use this bootloader for the pic32mk512mcf100 as well, is this the only part of the linker script I need to modify?
    MEMORY
    {
    /* All C files will be located here.*/
    kseg0_program_mem (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x100000 - 0x480
    kseg0_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x0
    kseg1_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x480
    kseg0_data_mem (w!x) : ORIGIN = 0x80000000 + 16, LENGTH = 0x40000 - 16 /* Reserve 16 Bytes to Store Bootloader Trigger Pattern */
    sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
    }
     
    If I were a betting man, I would say, I have to change that to this:
    MEMORY
    {
    /* All C files will be located here.*/
    kseg0_program_mem (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x80000 - 0x480
    kseg0_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x0
    kseg1_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x480
    kseg0_data_mem (w!x) : ORIGIN = 0x80000000 + 16, LENGTH = 0x20000 - 16 /* Reserve 16 Bytes to Store Bootloader Trigger Pattern */
    sfrs : ORIGIN = 0xBF800000, LENGTH = 0x80000
    }
     
    If that's correct, is that all that needs to change? 
    post edited by MPaulHolmes - 2020/06/06 10:30:27
    #12
    Jump to:
    © 2020 APG vNext Commercial Version 4.5