• AVR Freaks

Hot!PIC32MX Bootloader Problem

Author
mlg09001
Starting Member
  • Total Posts : 85
  • Reward points : 0
  • Joined: 2015/02/05 11:57:37
  • Location: 0
  • Status: offline
2015/08/28 13:58:31 (permalink)
0

PIC32MX Bootloader Problem

When I start off with the PIC just having the bootloader code and I use the bootloader to upload my code everything works correctly. But when I have the main code already loaded on, jump into the bootloader, load new main code on and send the run application command the gui loads with a solid picture of the old code main screen and loses functionality. When I unplugged and plug in the PIC, the problem is solved. Does anyone have any ideas why this is happening or how to fix it?
 
I am using the latest Harmony libraries, MPLAB X IDE, the AN1388 bootloader software, and the PIC32 GUI Development Board.
#1

12 Replies Related Threads

    maxruben
    Super Member
    • Total Posts : 3313
    • Reward points : 0
    • Joined: 2011/02/22 03:35:11
    • Location: Sweden
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/08/29 03:09:43 (permalink)
    0
    It could be that you haven't erased the flash for the application before programming in the new application. This means that you will only change 1s to 0s in the flash and the code could run if the memory isn't changed but will eventually hang.
     
    You can get this phenomenon if you erase in 4k steps with a PIC that only has 1k flash page size.
     
    Check if your app flash is fully erased with the debugger before reprogramming it.
     
    /Ruben
    #2
    mlg09001
    Starting Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2015/02/05 11:57:37
    • Location: 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/08/29 14:22:33 (permalink)
    0
    Thank you for the help. I don't have availability to my device until Monday so I won't be able to test that out until then. But if the flash isn't erased it seems like I couldn't get as far as I currently am.
     
    I am able to have my application code running, jump to the bootloader, load new application code in. But when the bootloader jumps to the new application code loaded, its just freezes with an image of the old code. The old code cant be anywhere in memory because I when I reset power to the device the new application code reappears (working properly) and I cant get this phenomenon to occur again.
    #3
    cgiordan
    Super Member
    • Total Posts : 1364
    • Reward points : 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/08/31 05:59:46 (permalink)
    0
    What about HW...  You initialize some HW peripheral perhaps - (timers, WDT, communications, etc.) and they aren't instantiated unless you perform a flash update process.  Perhaps this is why when you re-power the PIC32 after it hangs from updating, then it seemingly works.  I had a situation where I had the opposite occur.  When I loaded my target application, it instantiated several HW peripherals in the PIC32, then when I commanded it to branch to the BL from the target app., I didn't turn the WDT off before the branch, and my BL doesn't use the WDT...  Forgot to feed it!  Nonetheless, this is from my experience.  Make sure that your BL and Target App. are "re-initializing" the HW for the next application that is being handed the privilege to execute. 
    #4
    mlg09001
    Starting Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2015/02/05 11:57:37
    • Location: 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/08/31 06:11:23 (permalink)
    0
    It seems that may be my problem, as well. Is it possible to reinitialize all the peripherals after jumping to the application? My bootloader is just using uart, while my application is using uart and the graphics library, for the screen. I don't want to increase the size of the bootloader memory with having to include the graphics library.
    #5
    cgiordan
    Super Member
    • Total Posts : 1364
    • Reward points : 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/08/31 07:54:20 (permalink)
    3 (1)
    mlg09001
    It seems that may be my problem, as well. Is it possible to reinitialize all the peripherals after jumping to the application? My bootloader is just using uart, while my application is using uart and the graphics library, for the screen. I don't want to increase the size of the bootloader memory with having to include the graphics library.

    It is possible.  Simply revert what you modify in your BL to the default settings of the PIC32 - as if the Target pp. was only flashed and it started execution from a Power-On Reset (POR).  Simply instructions such as such:
     
    <peripheral register> = DEFAULT_VAL;
    ...
     
    I don't know specifically what your settings are for each peripheral you are using, but if you modify a particular peripheral register, revert it back to default value so when target application executes after a branch, the BL peripheral settings will not affect the Target App. functionality.  In other words, before branching at any time, reset the UART for instance manually.  Do this for each peripheral you use that may affect the Target App.  This may help your issue, but either way, it is good practice so you can eliminate a HW issue if it so persists currently. 
    #6
    maxruben
    Super Member
    • Total Posts : 3313
    • Reward points : 0
    • Joined: 2011/02/22 03:35:11
    • Location: Sweden
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/01 03:58:53 (permalink)
    3 (1)
    Just do a soft reset. The bootloader will start again but it should switch over to your app.
     
    /Ruben
    #7
    mlg09001
    Starting Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2015/02/05 11:57:37
    • Location: 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/01 04:43:47 (permalink)
    3 (1)
    Thank you for the help. It turns out I just needed to clear the error interrupt flag.
    #8
    cgiordan
    Super Member
    • Total Posts : 1364
    • Reward points : 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/01 12:21:08 (permalink)
    0
    mlg09001
    Thank you for the help. It turns out I just needed to clear the error interrupt flag.

    Which error interrupt flag?  Your target application should make sure before enabling an ISR source that it clears the flags and such - essentially complete, proper initialization - i.e. clearing flags, setting priority, etc.  This is the "safe" way to handle this.  Were you enabling an interrupt in your BL and you moved your IVT in the target application where the "new" table doesn't have a handler for the ISR?  This would cause a problem...  In this case, when you branch out of the BL, disable the ISR - via IECx register(s) - and clear the flags if necessary - IFSx register(s).  Performing a SW reset in this case is a "band-aid" rather than a root cause fix which will be to disable the HW - i.e. the interrupt controller settings that affect negatively in the Target App. 
     
    Remember, what you enable/disable prior to a branch will still remain enabled/disabled...  Make sure that you clean the slate before performing a branch so some "rogue" peripheral doesn't cause an issue in these BL/Target App. situations. 
    post edited by cgiordan - 2015/09/01 12:24:28
    #9
    mlg09001
    Starting Member
    • Total Posts : 85
    • Reward points : 0
    • Joined: 2015/02/05 11:57:37
    • Location: 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/01 12:28:02 (permalink)
    0
    It's the error uart interrupt flag that needed to be cleared. The bootloader has the default microchip setup for uart interrupts. My application code has a uart interrupt set up to check to see if the pic receives a certain sequence of bytes to jump back into the bootloader. I'm not sure why the bootloader caused this uart error interrupt flag, but clearing that flag at the end of the bootloader before jumping to the application fixed the problem. The uart communication on both the bootloader and application works correctly.
    Before clearing this flag at the end of the bootloader, when jumping to the application code it would just go right to the uart interrupt causing me a problem.
    #10
    cgiordan
    Super Member
    • Total Posts : 1364
    • Reward points : 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/01 12:31:24 (permalink)
    0
    mlg09001
    It's the error uart interrupt flag that needed to be cleared. The bootloader has the default microchip setup for uart interrupts. My application code has a uart interrupt set up to check to see if the pic receives a certain sequence of bytes to jump back into the bootloader. I'm not sure why the bootloader caused this uart error interrupt flag, but clearing that flag at the end of the bootloader before jumping to the application fixed the problem. The uart communication on both the bootloader and application works correctly.
    Before clearing this flag at the end of the bootloader, when jumping to the application code it would just go right to the uart interrupt causing me a problem.


    I would go one step further and disable the UART before branching while clearing all of the UART interrupt enable(s) and interrupt flag(s).  If you do this, you are solving the issue entirely.  You won't even get a UART error if it is disabled. 
    #11
    adamfolts
    Super Member
    • Total Posts : 218
    • Reward points : 0
    • Joined: 2010/10/19 08:32:20
    • Location: Prescott
    • Status: offline
    Re: PIC32MX Bootloader Problem 2015/09/02 12:53:04 (permalink)
    0
    In v1.06 of Harmony interrupts relating to the specific bootloader are disabled before application swapping. I would reference the updated Bootloader Harmony Framework for further assistance if needed. 
    #12
    anna.virabyan
    New Member
    • Total Posts : 9
    • Reward points : 0
    • Joined: 2019/01/30 03:18:54
    • Location: 0
    • Status: offline
    Re: PIC32MX Bootloader Problem 2019/02/01 00:59:12 (permalink)
    0
    Please help me, interrupt cause problem in app. I use USB hid bootloader without interrupt and i use app with timer interrupt. I generated projects with harmony. Bootloader works perfectly and app loaded to pic32mk by bootloader. But after interrupt event app hangs up. Without interrupt app works perfectly.
     
    This is a bootloader linker script
     
    /*************************************************************************
    * Processor-specific peripheral libraries are optional
    *************************************************************************/
    OPTIONAL("libmchp_peripheral.a")
    /*************************************************************************
    * For interrupt vector handling
    *************************************************************************/
    PROVIDE(_vector_spacing = 0x00000001);
    _ebase_address = 0x9FC01000;
    /*************************************************************************
    * Memory Address Equates
    * _RESET_ADDR -- Reset Vector
    * _BEV_EXCPT_ADDR -- Boot exception Vector
    * _DBG_EXCPT_ADDR -- In-circuit Debugging Exception Vector
    * _DBG_CODE_ADDR -- In-circuit Debug Executive address
    * _DBG_CODE_SIZE -- In-circuit Debug Executive size
    * _GEN_EXCPT_ADDR -- General Exception Vector
    *************************************************************************/
    _RESET_ADDR = 0xBFC00000;
    _BEV_EXCPT_ADDR = (0xBFC00000 + 0x380);
    _DBG_EXCPT_ADDR = (0xBFC00000 + 0x480);
    _DBG_CODE_ADDR = 0xBFC02000;
    _DBG_CODE_SIZE = 0xFF0;
    _GEN_EXCPT_ADDR = _ebase_address + 0x180;
    /*************************************************************************
    * Memory Regions
    *
    * Memory regions without attributes cannot be used for orphaned sections.
    * Only sections specifically assigned to these regions can be allocated
    * into these regions.
    *************************************************************************/
    MEMORY
    {
    kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x7000 /* All C Files will be located here */
    kseg0_boot_mem : ORIGIN = 0x9FC00490, LENGTH = 0x0 /* This memory region is dummy */
    exception_mem : ORIGIN = 0x9FC01000, LENGTH = 0x1000 /* Interrupt vector table */
    config3 : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
    config2 : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
    config1 : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
    config0 : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
    kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x300 /* C Startup code */
    kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000
    sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
    debug_exec_mem : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
    configsfrs : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
    }
     
     
    This is a app linker script 
     
    /*************************************************************************
    * Processor-specific object file. Contains SFR definitions.
    *************************************************************************/
    INPUT("processor.o")

    /*************************************************************************
    * Processor-specific peripheral libraries are optional
    *************************************************************************/
    OPTIONAL("libmchp_peripheral.a")
    /*************************************************************************
    * For interrupt vector handling
    *************************************************************************/
    PROVIDE(_vector_spacing = 0x00000001);
    _ebase_address = 0x9D008000;
    /*************************************************************************
    * Memory Address Equates
    * _RESET_ADDR -- Reset Vector
    * _BEV_EXCPT_ADDR -- Boot exception Vector
    * _DBG_EXCPT_ADDR -- In-circuit Debugging Exception Vector
    * _DBG_CODE_ADDR -- In-circuit Debug Executive address
    * _DBG_CODE_SIZE -- In-circuit Debug Executive size
    * _GEN_EXCPT_ADDR -- General Exception Vector
    *************************************************************************/
    _RESET_ADDR = (0x9D007000);
    _GEN_EXCPT_ADDR = _ebase_address + 0x180;
    /*************************************************************************
    * Memory Regions
    *
    * Memory regions without attributes cannot be used for orphaned sections.
    * Only sections specifically assigned to these regions can be allocated
    * into these regions.
    *************************************************************************/
    MEMORY
    {
    kseg0_program_mem (rx) : ORIGIN = (0x9D000000 + 0x7000), LENGTH = (0x80000 - 0x7000) /* All C Files will be located here */
    kseg0_boot_mem : ORIGIN = 0x9D000000 + 0x7000, LENGTH = 0x0 /* This memory region is dummy */
    config3 : ORIGIN = 0xBFC02FF0, LENGTH = 0x4
    config2 : ORIGIN = 0xBFC02FF4, LENGTH = 0x4
    config1 : ORIGIN = 0xBFC02FF8, LENGTH = 0x4
    config0 : ORIGIN = 0xBFC02FFC, LENGTH = 0x4
    kseg1_data_mem (w!x) : ORIGIN = 0xA0000000, LENGTH = 0x20000
    sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
    debug_exec_mem : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
    configsfrs : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
    }
    post edited by anna.virabyan - 2019/02/01 01:01:56
    #13
    Jump to:
    © 2019 APG vNext Commercial Version 4.5