• AVR Freaks

Hot!PIC32MZ Bootloader Still Not Working

Author
hala9k
Starting Member
  • Total Posts : 37
  • Reward points : 0
  • Joined: 2011/01/19 10:55:24
  • Location: 0
  • Status: offline
2020/02/13 00:56:40 (permalink)
5 (1)

PIC32MZ Bootloader Still Not Working

Hi All,
 
I have been working on getting this bootloader working for too long now, still can't figure it out. It is essentially the same as the one I've been using in PIC32MX695s, very reliably. That product uses the legacy non-harmony TCPIP stack, and XC32 v1.33.
 
This project is a newer version of that same product, using a PIC32MZ2048EFM144, with MPLABX v5.05, XC32 v2.10, and the Oryx non-harmony stack.
 
Most of the application is done, using 53% code space, and works well. From the application I can upload the unified hex file into SPI flash and check it pretty thoroughly. On apply, I set a code in a location in SPI flash, then force a reset. Reset goes to the bootloader and, if it finds the code, applies the hex file. If not, it skips straight to the application.
 
The problem is that if it applies the hex file it will then jump to the app, as it should, but only the first few lines of main() will execute before resetting back to the bootloader (to start programming again). This is the same hex file that runs fine if the bootloader doesn't run. I have changed just about everything I can think of but it always gets the same result (or worse).
 
I've included the linker scripts and bootloader code, maybe someone will spot the problem right away. I've run out of ideas.
 
Thanks, Hal
 
BTW, these linker scripts are sort of cobbled together from items here on the forums. They could probably be improved. Also, I'm limited to 5 files attached so I left out the .h files. Here are some relevant defines in Bootloader.h:

#define APP_FLASH_BASE_ADDRESS     0x9D000000
#define APP_FLASH_END_ADDRESS   0x9D200000  //

/* Address of  the Flash from where the application starts executing */

#define USER_APP_RESET_ADDRESS     0x9D000000

// PIC32MZ?
#define FLASH_PAGE_SIZE                 4096
#define DEV_CONFIG_REG_BASE_ADDRESS 0xBFC0FF40
#define DEV_CONFIG_REG_END_ADDRESS   0xBFC6FFC0


 

Attachment(s)

Attachments are not available: Download requirements not met
#1

9 Replies Related Threads

    NKurzman
    A Guy on the Net
    • Total Posts : 18388
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 06:02:21 (permalink)
    +1 (1)
    Did your bootloader disable All the interrupt enables before launching the main app? Not just the master.
    #2
    Jim Nickerson
    User 452
    • Total Posts : 6566
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 07:53:38 (permalink)
    0
    and disable the watchdog till the app starts up
    and implement all exception handlers.
    #3
    hala9k
    Starting Member
    • Total Posts : 37
    • Reward points : 0
    • Joined: 2011/01/19 10:55:24
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:08:24 (permalink)
    0
    I'm not using the watchdog at all, and I have it turned off in the configuration bits. Interrupts are not enabled until much farther down in main(). I even tried adding a line to explicitly turn them off ahead of the point where it resets back to the bootloader, no change.
    #4
    Jim Nickerson
    User 452
    • Total Posts : 6566
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:11:50 (permalink)
    0
    sad: sad
    #5
    hala9k
    Starting Member
    • Total Posts : 37
    • Reward points : 0
    • Joined: 2011/01/19 10:55:24
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:19:32 (permalink)
    0
    I'm not using any interrupts in the bootloader, and I never enable any there. They are normally enabled farther down in the app, well past the point where it resets back to the bootloader. I did try adding a line to disable them ahead of where it resets just to make sure but it didn't change anything.
     
    #6
    Jim Nickerson
    User 452
    • Total Posts : 6566
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:23:07 (permalink)
    0
    maybe you could try this to debug them together https://microchipdeveloper.com/mplabx:projects-loadable-bootloaders
    #7
    hala9k
    Starting Member
    • Total Posts : 37
    • Reward points : 0
    • Joined: 2011/01/19 10:55:24
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:24:01 (permalink)
    0
    You're telling me. This is the last major piece I need to finish this project. Once this is done I can get some field test units out and deal with any remaining bugs as they come up.
     
    #8
    hala9k
    Starting Member
    • Total Posts : 37
    • Reward points : 0
    • Joined: 2011/01/19 10:55:24
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/13 10:33:22 (permalink)
    0
    I'm not getting any conflicts during compile and linking, and everything runs fine when the pickit programs the part. it's only when the bootloader actually programs it, even using the exact same unified hex file, that I get the problem.
     
    #9
    hala9k
    Starting Member
    • Total Posts : 37
    • Reward points : 0
    • Joined: 2011/01/19 10:55:24
    • Location: 0
    • Status: offline
    Re: PIC32MZ Bootloader Still Not Working 2020/02/27 16:43:36 (permalink)
    0
    Well, I did find the problem, after a lot of tedious debugging. It turns out that checking the hex file "pretty thoroughly" isn't good enough. The HTTP POST upload process modifies the incoming buffer as it watches for the ending boundary, which begins with "crlf". Each line of a hex file also ends with crlf, and occasionally (200K-300K bytes) it falls just right. What threw me is that the character count was always correct. Once I figured out to save the incoming buffer after the boundary check (which also modifies the character count) I stopped getting errors, and the bootloader worked just fine.
     
    Thanks, Hal
    #10
    Jump to:
    © 2020 APG vNext Commercial Version 4.5