• AVR Freaks

Hot!PIC32MZ bootloader, unified hex working, bootloaded hex crashes

Author
hamster
New Member
  • Total Posts : 10
  • Reward points : 0
  • Joined: 2019/08/23 06:16:37
  • Location: 0
  • Status: offline
2019/11/08 06:30:00 (permalink)
0

PIC32MZ bootloader, unified hex working, bootloaded hex crashes

I am using a PIC32MZ2048EFH144 with Harmony v2.06. I have made an SD card bootloader starting off from the example application in Harmony. If I compile the bootloader with the application as a loadable project everything work as expected, however, when I try to load the application with the bootloader it crashes during the second run-through of SYS_Tasks(). I have a few questions regarding that topic:

By toggling some LEDs I am able to see that the application has been loaded to program memory, but it crashes during a call to:
DRV_SDCARD_Tasks(sysObj.drvSDCard);
I comment out this line as the SD card is not crucial to the application, but now it crashes at:
DRV_USBHS_Tasks(sysObj.drvUSBObject);


1. Anyone experienced anything like this? Again, when the bootloader and the application is compiled together and loaded by the PICkit as a unified hex, the app runs without error. Could it still be due to a mismatch of the system config in the bootloader project and the application project? But why doesnt it surface in the unified hex?
2. Is there a good way to debug this scenario? Could I generate an hex with debug signals and debug the application after its been loaded into program memory by the bootloader?
#1

11 Replies Related Threads

    hamster
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2019/08/23 06:16:37
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2019/11/10 04:43:26 (permalink)
    0
    If this was not entirely clear from the first post:
    I compile and program a unified hex with the bootloader and the application onto the PIC32. The application runs as expected. But when I use the bootloader to load a new version of the application into program memory (by new I mean just toggeling som LEDs to demonstrate that I actually managed to update the program memory with a new application) I experience problems. The bootloader does indeed update the program memory but the new application crashes.

    Is this a typical problem? What can cause this? The very same application works as expected when compiled together with the Bootloader.
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 18141
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2019/11/10 11:12:03 (permalink)
    5 (1)
    Is IPE to extract the working and non working hex images and save them.
    Use a tool like “Beyond Compare” to compare the two hex files.
    See why they are different.
    Look for differences in the application. And in the bootloader.
    #3
    Jim Nickerson
    User 452
    • Total Posts : 6414
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2019/11/10 11:28:50 (permalink)
    0
    you might use the  ELFviewer plugin while building the application to see what memory  it is writing to.
    #4
    hamster
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2019/08/23 06:16:37
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2019/11/15 07:28:45 (permalink)
    0
    Using MPLAB and PICkit4 I can read out the unified HEX and then the HEX file after a new application HEX has been loaded to program memory by the bootloader. I have tried using Beyond Compare to compare them, but I dont understand the byte addressing? It seems to only contain addresses from 0x0000-> 0x65BDBC. The program memory is, for instance at: 0x1D000000? Maybe I  (and also not Beyond Compare) dont understand the HEX file format.

    The ELFviewer worked pretty well, but the bootloader elf apparantly doesnt include the loadable project. So I basically only see the bootloader part and not the loaded project part. Because unification combines the 2 HEX files, and my problem is that it does not combine them in an expected way.

    I have been googeling alot and I am pretty sure that this problem is due to some mistake in my linker scripts. I must admit that this was a new topic for me, so I have made the linkerfiles based  on various posts to this forum.

    I add both my linker files here in the hopes that someone could point out an obvious mistake. The general though behind the linker scripts are:

    Bootloader.lkr:
    - Point kseg0_program_mem to the BOOT_FLASH and load the whole bootloader application there
    - Exception_mem (where the IVT lives are loaded also to BOOT_FLASH at same place as ebase_address
    Application.lkr:
    - Point kseg0_program_mem to PROGRAM_FLASH and load the whole application there
    -  exception_mem is in PROGRAM_FLASH and at ebase_address

    I am very grateful for any feedback and help, I have spent a lot of time pulling my hair here.

    Thanks,
    Erling



     
     


    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 18141
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2019/11/15 09:06:19 (permalink)
    0
    Read the format for a hex file.
    Note it will be the physical address.
    You will need to find the record with the upper byte.

    Beyond compare does not care about hex files. If you followed the instructions I gave you would get two memory images that should be identical.
    The bottom better be since it is the bootloader.
    Yes linker files can be a problem if the two overlap.
    #6
    hamster
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2019/08/23 06:16:37
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/10 09:09:02 (permalink)
    4 (1)
    For anyone interested. The problem was that the Interrupt Vector Table was placed by the application linker at 0x1D000200 and in the bootloader source code the APP_FLASH_BASE was set to 0x1D001000. I.e. the IVT was not within the APP_FLASH range. I moved the IVT and now it works.

    A follow-up question.
    Now I have the bootloader working, but still when I inspect the hex read out from the PIC32 I see that the following symbols are missing:
    _SIMPLE_TLB_REFILL_EXCPT_ADDR   = _ebase_address + 0;
    _CACHE_ERR_EXCPT_ADDR           = _ebase_address + 0x100;
    _GEN_EXCPT_ADDR                 = _ebase_address + 0x180;

    In the unified hex they are found at their respective addresses, but when i bootload a new app they are FF'ed out. Anyone know why? And what implications this has? Is it because
    APP_FLASH_BASE = _ebase_address + 0x1000?
    #7
    friesen
    Super Member
    • Total Posts : 2096
    • Reward points : 0
    • Joined: 2008/05/08 05:23:35
    • Location: Indiana, USA
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/10 10:08:00 (permalink)
    0
    Does your app use FreeRTOS?

    Erik Friesen
    #8
    aschen0866
    Super Member
    • Total Posts : 4525
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/10 14:42:07 (permalink)
    0
    hamster
    For anyone interested. The problem was that the Interrupt Vector Table was placed by the application linker at 0x1D000200 and in the bootloader source code the APP_FLASH_BASE was set to 0x1D001000. I.e. the IVT was not within the APP_FLASH range. I moved the IVT and now it works.

    The problem is that in your application linker script, you have

    /* Interrupt vector table with vector offsets */
    .vectors _ebase_address + 0x200 :
    {
    ...
    } > kseg0_program_mem

    It should be

    /* Interrupt vector table with vector offsets */
    .vectors _ebase_address + 0x200 :
    {
    ...
    } > exception_mem

    since you have already allocated a memory region for the vector table.
    #9
    hamster
    New Member
    • Total Posts : 10
    • Reward points : 0
    • Joined: 2019/08/23 06:16:37
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/11 03:12:17 (permalink)
    0
    friesen:
    My app is bare metal. How would using FreeRTOS or not affect this?

    aschen0866:
    Thank your for pointing that out. I should read up on linker scripts. Do you have any comment to why:
    _SIMPLE_TLB_REFILL_EXCPT_ADDR   = _ebase_address + 0;
    _CACHE_ERR_EXCPT_ADDR           = _ebase_address + 0x100;
    _GEN_EXCPT_ADDR                 = _ebase_address + 0x180;

    are not present in the bootloaded image, and how it could affect the app?

    Thanks again.
    #10
    friesen
    Super Member
    • Total Posts : 2096
    • Reward points : 0
    • Joined: 2008/05/08 05:23:35
    • Location: Indiana, USA
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/11 07:22:11 (permalink)
    0
    I'm just asking, because with bootloaded FreeRTOS the vector table / _ebase_address needs to be aligned 0x4000 for some unknown reason or it crashes.

    Erik Friesen
    #11
    aschen0866
    Super Member
    • Total Posts : 4525
    • Reward points : 0
    • Joined: 2006/01/08 22:18:32
    • Location: San Diego
    • Status: offline
    Re: PIC32MZ bootloader, unified hex working, bootloaded hex crashes 2020/01/11 09:27:50 (permalink)
    0
    hamster
    ... Do you have any comment to why:
    _SIMPLE_TLB_REFILL_EXCPT_ADDR   = _ebase_address + 0;
    _CACHE_ERR_EXCPT_ADDR           = _ebase_address + 0x100;
    _GEN_EXCPT_ADDR                 = _ebase_address + 0x180;

    are not present in the bootloaded image, and how it could affect the app?



    These output section regions should be changed to exception_mem as well.

    .simple_tlb_refill_excpt _SIMPLE_TLB_REFILL_EXCPT_ADDR :
    {
    KEEP(*(.simple_tlb_refill_vector))
    } > kseg0_program_mem
    .cache_err_excpt _CACHE_ERR_EXCPT_ADDR :
    {
    KEEP(*(.cache_err_vector))
    } > kseg0_program_mem

    #12
    Jump to:
    © 2020 APG vNext Commercial Version 4.5