• AVR Freaks

Hot!PIC32MZ bootlader Harmony (USB). Help with the ld file for application.

Page: 12 > Showing page 1 of 2
Author
DominusT
Super Member
  • Total Posts : 1334
  • Reward points : 0
  • Joined: 2005/07/22 08:31:18
  • Status: offline
2019/04/26 07:35:58 (permalink)
0

PIC32MZ bootlader Harmony (USB). Help with the ld file for application.

Hi.
 
I have managed to create a bootlader for the PIC32MZ Curiosity board based on the 'basic' bootloader with Hamony v 2.06.


The bootloader works correctly since I can get the version of it, delete the memory and program program memory vía USB (device)

But when I download the program the application doesn't work and it is most likely that the limits defined for the bootloader and the application are not correct.

In the bootloader the limits are defined as follows:

/* APP_FLASH_BASE_ADDRESS and APP_FLASH_END_ADDRESS reserves program Flash for the application*/
/* Rule:
    1)The memory regions kseg0_program_mem, kseg0_boot_mem, exception_mem and
    kseg1_boot_mem of the application linker script must fall with in APP_FLASH_BASE_ADDRESS
    and APP_FLASH_END_ADDRESS

    2)The base address and end address must align on boundaries according to the flash page size */
#define APP_FLASH_BASE_ADDRESS (0x9D000000)

#define APP_FLASH_END_ADDRESS (0x9D000000 + 0x200000 - 1)

/* Address of the Flash from where the application starts executing */
/* Rule: Set APP_FLASH_BASE_ADDRESS to _RESET_ADDR value of application linker script*/
#define APP_RESET_ADDRESS (APP_FLASH_BASE_ADDRESS)

 
While in the app_mz.ld file generated with Harmony with the MHC, the limits are defined as follows:

MEMORY
{
    kseg1_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x480
    kseg0_program_mem (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x200000 - 0x480 /* All C files will be located here */
    kseg0_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x0
  kseg0_data_mem (w!x) : ORIGIN = 0x80000000, LENGTH = 0x80000
  sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
  kseg2_ebi_data_mem : ORIGIN = 0xC0000000, LENGTH = 0x4000000
  kseg2_sqi_data_mem : ORIGIN = 0xD0000000, LENGTH = 0x4000000
  kseg3_ebi_data_mem : ORIGIN = 0xE0000000, LENGTH = 0x4000000
  kseg3_sqi_data_mem : ORIGIN = 0xF0000000, LENGTH = 0x4000000
}

 
 
Any comments or suggestions are welcome
 
 
post edited by DominusT - 2019/04/26 15:13:57
#1

34 Replies Related Threads

    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/04/26 12:01:20 (permalink)
    0
    I have reviewed both the 'basic' example and the example to be programmed called 'dma_led_pattern' and its ld files match my projects.

    I feel that something else I should do in the application project.
    #2
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/04/27 13:09:45 (permalink)
    0
    I have merged the two programs, application and bootloader in a single project as indicated by the Harmony help (Volume V: MPLAB Harmony Framework Reference> Bootloader Library Help> Bootloader Sizing and Optimization, Debugging with a Bootloader and an Application).


    And the user application works correctly, ie the bootlader detects that there is an application and the program point goes to that address and works well.


    The problem is when I compile separately, the bootloader and the user application.


    I found in this thread that something similar happened:

    https://www.microchip.com/forums/m887384.aspx


    After downloading to delete and program program memory, verification fails.
     
    I've also verified where the bootloader and the user extension are with the ELFViewer and everything seems fine
     
     
    #3
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 14:03:09 (permalink)
    0
    Hi.
     

    I opened a technical support for this problem but who is helping me seems to be a novice with respect to the bootloader and we have been without progress for quite some time.

    Something that has constantly told me is that I check the limits set in the bootloader in the * .ld file, but I have already indicated that they are within the indicated.
     
    MEMORY
    {
        kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x480
        kseg0_program_mem (rx) : ORIGIN = 0x9fc01000, LENGTH = 0xFF00 - 0x1000
        kseg0_boot_mem : ORIGIN = 0x9fc004b0, LENGTH = 0x00000000
      kseg1_boot_mem_4B0 : ORIGIN = 0xBFC004B0, LENGTH = 0x1000 - 0x4B0

     
    The second is the base address in the bootloader that is defined in the system_config.h file

    #define APP_FLASH_BASE_ADDRESS (0x9D000000)

    #define APP_FLASH_END_ADDRESS (0x9D000000 + 0x200000 - 1)

    /* Address of the Flash from where the application starts executing */
    /* Rule: Set APP_FLASH_BASE_ADDRESS to _RESET_ADDR value of application linker script*/
    #define APP_RESET_ADDRESS (APP_FLASH_BASE_ADDRESS)

    --------------------------------------------------------------------------------------------
    With respect to the user application, the ld file also has its limits defined correctly.

    MEMORY
    {
        kseg1_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x480
        kseg0_program_mem (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x200000 - 0x480 /* All C files will be located here */
        kseg0_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x0 
      kseg0_data_mem (w!x) : ORIGIN = 0x80000000, LENGTH = 0x80000
      sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
      kseg2_ebi_data_mem : ORIGIN = 0xC0000000, LENGTH = 0x4000000
      kseg2_sqi_data_mem : ORIGIN = 0xD0000000, LENGTH = 0x4000000
      kseg3_ebi_data_mem : ORIGIN = 0xE0000000, LENGTH = 0x4000000
      kseg3_sqi_data_mem : ORIGIN = 0xF0000000, LENGTH = 0x4000000
    }


    I have also used the ELFViewer tool for the bootloader (image ELVViewer for bootloader.png) and for the user application (image ELVViewer for user app.png) and it can be clearly seen that applications occupy their respective regions correctly.


    Please, there is someone who can tell me what the problem may be.
    From my point of view, they are the limits of one of the ld file (bootloader or user app).
    post edited by DominusT - 2019/07/01 14:04:37

    Attached Image(s)

    #4
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 17:07:03 (permalink)
    0
    I never got an useful help fro Microchip on a Harmony Bootloader.
    Which PIC are you using?
     
    I have some Old Posts about the Issue with the Bootloaders. There are Post from those that helped, And a Final working script.  Note for the PIC32 there can be several ways to do certain things . This means there is more than one correct script.  One issue is the Linker does not appear to recognize overlapping addresses in the overlapping memory spaces. And may ignore addresses that are in the wrong space with no warning.  Some of this is noted in my PIC32MX Bootloader.  The Issue with some of the PIC32MZ linker scripts is the Interrupt area is dynamic.  So not enough space for it was left open.
    #5
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 18:00:25 (permalink)
    0
    NKurzman
    I never got an useful help fro Microchip on a Harmony Bootloader.
    Which PIC are you using?
     
    I have some Old Posts about the Issue with the Bootloaders. There are Post from those that helped, And a Final working script.  Note for the PIC32 there can be several ways to do certain things . This means there is more than one correct script.  One issue is the Linker does not appear to recognize overlapping addresses in the overlapping memory spaces. And may ignore addresses that are in the wrong space with no warning.  Some of this is noted in my PIC32MX Bootloader.  The Issue with some of the PIC32MZ linker scripts is the Interrupt area is dynamic.  So not enough space for it was left open.


    Thanks for write.
    I am working with the PIC32MZ2048EFM100 (PIC32 Curiosity board).

    I'm taking the example of bootloader for the Starter Kit board (pic32mz_ef_sk) since it's the same MCU and to generate the ld file of the user application I'm doing what the Harmony help says. Attached image (In my case I am using USB HID)

    Attached Image(s)

    #6
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 18:16:23 (permalink)
    0
    Unless they changed it. 
    You create the Linker script for the Application In the Bootloader, Then you manually add it to the Application project, and check use response file to link in the Project properties Xc32-ld tab.
    Note the application will not run standalone with their linker script.
     
     There should be instructions in the Harmony Help.
    #7
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 18:26:22 (permalink)
    0
    NKurzman
    Unless they changed it. 
    You create the Linker script for the Application In the Bootloader, Then you manually add it to the Application project, and check use response file to link in the Project properties Xc32-ld tab.
    Note the application will not run standalone with their linker script.
     
     There should be instructions in the Harmony Help.


    The ld file of the bootlader is the same as the one provided in the Harmony example (btl_mz.ld), that is, the bootlaoder I'm using is the example called BASIC which I have not modified anything, while the ld file for user app is created by MHC as I indicated above and sai file is automatically added to the project in the folder 'linker files'
    post edited by DominusT - 2019/07/01 18:30:40
    #8
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 18:27:28 (permalink)
    0
    I attached 2 images of the ELFViewer tool where it is much better to see where the code start for the bootloader and the user application.

    Attached Image(s)

    #9
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/01 20:36:58 (permalink)
    0
    The app should get app_mz.ld (or something like that)
    #10
    Paul PortSol
    Super Member
    • Total Posts : 509
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: Newfoundland, Canada
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/02 06:14:00 (permalink)
    0
    My own experience wasn't quick with PIC32 and Harmony Bootloaders.
    I needed a custom protocol to load through our interfaces, and my bootloaders were fairly long since I didn't have time to optimize them. In the end I got it working from loading files froma central module with USB, sending over a custom network, and loading into PIC32MX and PIC32MZ modules.
     
    Things to be careful of:
    a) The example bootloaders are just examples, not production ready. They have some assumptions that can become issues. For example they don't necessarily block loading code at memory addresses reserved in the particular MCU. So you'll have to read datasheets unless your app is so tiny the loading doesn't ever reach the restricted addresses.
     
    b) If the bootloading process is going to be done by anyone other than the developer, then you'll probably want to write a cleaner dedicated tool as unfamiliar users are going to hit speedbumps in the process that won't be resolved by a one page quick ref.
     
    c) The vectors in the ld file may change depending on the modules you've enabled in MHC (Ii'm not sure about this, but ignoring it did cause me issues so be careful to do full file compare for ld files when you enable/disable other modules.)
     
    d) If writing a custom bootloader It may be best to only salvage the ld files as starting points. Trying to modify the existing loader code ended up with a mess for me (though was good for learning what needed to be done), and I wrote from scratch once I understood what was needed.
     
    e) Attached are some sample ld files for loaded and loader for PIC32MZ. These are working now, but could use further work (I am by no means an expert with PIC32 linker files).
    - ld_pr_v00_20190702.zip
     
    f) I found it useful to generate dummy projects with various types of loaders (serial, usb, ethernet, etc.) just to see the differences in the ld files for different sizes of loader/loaded.
    ** I am still concerned that regions marked "protected/restricted" in datasheets don't seem to be acknowledged in the linker scripts, leading to code being linked into unable areas for some longer loaders/loadeds.
     
    *) If you check my posts a few months back you might find more about my results and issues.
     
    Paul
     
     
     
     
    #11
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader HArmony. Help with the ld file for application. 2019/07/02 06:14:55 (permalink)
    0
    NKurzman
    The app should get app_mz.ld (or something like that)

    Of course, as indicated above, in the user application using the MHC you must enable the option 'Use Bootloader Library?' and for my case I must choose USB_DEVICE and finally select 'Build an Application Linker Script'. Attached image called linker_script_for_app_user.
     
    then, generated the code with the MHC, the ld file is attached to the project (user application), which is called app_mz.ld, please look at the image named file_id_in_app_user

    And the limits of the memory addresses of the MCU are apparently correct:


     
    MEMORY
    {
    kseg1_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x480
    kseg0_program_mem (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x200000 - 0x480 /* All C files will be located here */
    kseg0_boot_mem : ORIGIN = 0x9D000000, LENGTH = 0x0
    kseg0_data_mem (w!x) : ORIGIN = 0x80000000, LENGTH = 0x80000
    sfrs : ORIGIN = 0xBF800000, LENGTH = 0x100000
    kseg2_ebi_data_mem : ORIGIN = 0xC0000000, LENGTH = 0x4000000
    kseg2_sqi_data_mem : ORIGIN = 0xD0000000, LENGTH = 0x4000000
    kseg3_ebi_data_mem : ORIGIN = 0xE0000000, LENGTH = 0x4000000
    kseg3_sqi_data_mem : ORIGIN = 0xF0000000, LENGTH = 0x4000000
    }
     

     
    As indicated above, the bootloader works because you can communicate with it. It is possible to ask for its version, you can ask it to delete the program memory and it says that this action has been carried out successfully, you can load the file * .hex of the user application that was created with the file app_mz.ld and 'program' all the memory without problems, but when you send the command jump to application, the MCU does nothing, it is as if a corrupt application has been written in the program memory.


    By means of the button on the board you can return to the bootlader again, you have pressed it, and the watchdog reboots the MCU (since the application does not work correctly) and again the MCU executes the bootloader.


    Someone may say that the user application is defective, but it is not. If you compile the project WITHOUT THE FILE app_mz.ld and download it to the MCU, the application works without problems.
     
     
     

    Attached Image(s)

    #12
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/02 06:24:11 (permalink)
    0
     
    Paul PortSol
    My own experience wasn't quick with PIC32 and Harmony Bootloaders.
    I needed a custom protocol to load through our interfaces, and my bootloaders were fairly long since I didn't have time to optimize them. In the end I got it working from loading files froma central module with USB, sending over a custom network, and loading into PIC32MX and PIC32MZ modules.
     
    Things to be careful of:
    a) The example bootloaders are just examples, not production ready. They have some assumptions that can become issues. For example they don't necessarily block loading code at memory addresses reserved in the particular MCU. So you'll have to read datasheets unless your app is so tiny the loading doesn't ever reach the restricted addresses.
     
    b) If the bootloading process is going to be done by anyone other than the developer, then you'll probably want to write a cleaner dedicated tool as unfamiliar users are going to hit speedbumps in the process that won't be resolved by a one page quick ref.
     
    c) The vectors in the ld file may change depending on the modules you've enabled in MHC (Ii'm not sure about this, but ignoring it did cause me issues so be careful to do full file compare for ld files when you enable/disable other modules.)
     
    d) If writing a custom bootloader It may be best to only salvage the ld files as starting points. Trying to modify the existing loader code ended up with a mess for me (though was good for learning what needed to be done), and I wrote from scratch once I understood what was needed.
     
    e) Attached are some sample ld files for loaded and loader for PIC32MZ. These are working now, but could use further work (I am by no means an expert with PIC32 linker files).
    - ld_pr_v00_20190702.zip
     
    f) I found it useful to generate dummy projects with various types of loaders (serial, usb, ethernet, etc.) just to see the differences in the ld files for different sizes of loader/loaded.
    ** I am still concerned that regions marked "protected/restricted" in datasheets don't seem to be acknowledged in the linker scripts, leading to code being linked into unable areas for some longer loaders/loadeds.
     
    *) If you check my posts a few months back you might find more about my results and issues.
     
    Paul
     

     
    Thank you very much for answering.
    I will review your attachment. I also think I should try to load a simpler user application. The user application also uses the USB module, but in CDC mode. Maybe that is the reason for the problem.

    Thanks again
     
     
    post edited by DominusT - 2019/07/02 06:31:49
    #13
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/02 08:09:21 (permalink)
    0
    I thought that maybe using the USB module in the user application generated some kind of problem in conjunction with a USB bootloader.
    I just made a simple project where a led flashes without the intervention of a special peripheral and the result is the same problem.
    #14
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/02 08:59:23 (permalink)
    0
    one thing to check.  Make sure all the Interrupt enables are clear.
    IEC0 = 0x0000; // Disable All individual interrupts (just to be sure)
    IEC1 = 0x0000;
    IEC2 = 0x0000;
    IEC3 = 0x0000;
    IEC4 = 0x0000;
    IEC5 = 0x0000;
    Harmony does not always do it.
     
    -
     
    Then make sure you code is loaded.
    Burn it to the PIC.  Read it back and save it.
    Burn the Bootloader. Read it back and save it.
    Boot load the App to the PIC. Read it back and save it.
    Use a file compare utility to look for missing or overlapped memory.
     
     
    You can add some thing like this to sections in the Application script.  It will add a jump to the application so it will skip the missing bootloader.  Note the Bootloader would need to ignore this write to avoid trashing the reset address.  this jumps to 0xBD000010  This will tell you your application works at the address it was moved to.
     
     
    SECTIONS
    {
    .startup_without_bootloader _RESET_ADDR :
    {
    LONG (0x3c1abd00);
    LONG (0x375a0010);
    LONG (0x03400008);
    LONG (0);
    } > kseg1_boot_mem
     
     
    #15
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/04 06:58:25 (permalink)
    0
    Paul PortSol
    My own experience wasn't quick with PIC32 and Harmony Bootloaders.
    I needed a custom protocol to load through our interfaces, and my bootloaders were fairly long since I didn't have time to optimize them. In the end I got it working from loading files froma central module with USB, sending over a custom network, and loading into PIC32MX and PIC32MZ modules.
     
    Things to be careful of:
    a) The example bootloaders are just examples, not production ready. They have some assumptions that can become issues. For example they don't necessarily block loading code at memory addresses reserved in the particular MCU. So you'll have to read datasheets unless your app is so tiny the loading doesn't ever reach the restricted addresses.
     
    b) If the bootloading process is going to be done by anyone other than the developer, then you'll probably want to write a cleaner dedicated tool as unfamiliar users are going to hit speedbumps in the process that won't be resolved by a one page quick ref.
     
    c) The vectors in the ld file may change depending on the modules you've enabled in MHC (Ii'm not sure about this, but ignoring it did cause me issues so be careful to do full file compare for ld files when you enable/disable other modules.)
     
    d) If writing a custom bootloader It may be best to only salvage the ld files as starting points. Trying to modify the existing loader code ended up with a mess for me (though was good for learning what needed to be done), and I wrote from scratch once I understood what was needed.
     
    e) Attached are some sample ld files for loaded and loader for PIC32MZ. These are working now, but could use further work (I am by no means an expert with PIC32 linker files).
    - ld_pr_v00_20190702.zip
     
    f) I found it useful to generate dummy projects with various types of loaders (serial, usb, ethernet, etc.) just to see the differences in the ld files for different sizes of loader/loaded.
    ** I am still concerned that regions marked "protected/restricted" in datasheets don't seem to be acknowledged in the linker scripts, leading to code being linked into unable areas for some longer loaders/loadeds.
     
    *) If you check my posts a few months back you might find more about my results and issues.
     
    Paul
     

    Hi.

    I'm using the ld files that you have provided to me, it seems that something tries to do the MCU when trying to jump to the user application, the problem is that I don't have the criteria to define the base address and the final address in the system_config file. h of the bootloader project:

    #define APP_FLASH_BASE_ADDRESS (0x???????????)//(0x9D000000)
    #define APP_FLASH_END_ADDRESS (0x???????? + 0x????? - 0x01)//(0x9D000000 + 0x200000 - 1)




    #16
    Paul PortSol
    Super Member
    • Total Posts : 509
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: Newfoundland, Canada
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/04 07:59:26 (permalink)
    0
    Body will be added in after posting due to the strict checks blocking for some weird reason (happens sometimes)
     
    Yes, there is a mess of stuff, and a mess more speedbumps that I only recall piecemeal.
     
    g) Ensure that "loadable" projects have "short names". No idea why but if a project won't link properly with a loadable, rename the target loadable to something short, rebuild it, select it fresh as a loadable, and try again. I've been bitten a few times.
    (Maybe try under 10 char project name length till sure, though I think real cutoff may be over 20char).
     
    h) There are some files that need to be matched to the project's ld file. See attached zip for some examples (mix of possibly useful stuff). I'm busy with my own projects so no time to write a full guide, so you'll have to put in a lot of time to make it work. Even if I wrote up more I'm sure it would be half obsoleted with next microchip update :/
    Search your project for the files with addresses like 0x9d000000, and prepare to adjust those lines to match your customized ld file (I can't remember the name of the original generated file).
     
    Below is an excerpt from one of my header files with the lines modified for the adjusted addresses, and also renamed to match labels in my custom loaded app & bootloader projects.
     

     
    #define D_BL_Len (0xFF00 - 0x1000) //From btl_mz.ld

    ///AppLoaded: Loaded Application Code for Module normal operation
    #define D_APP_BASE_ADDRESS (0x9d000000) //Exclude 0x18000 (Bootloader+FactFLASH+DataFLASH)
    #define D_APP_LEN (0x200000 - (D_DataFLASH_Reserve))
    #define D_APP_END_ADDRESS (D_APP_BASE_ADDRESS + D_APP_LEN - 1) //Fixed by PIC32 IC
    #define D_APP_RESET_ADDRESS (D_APP_BASE_ADDRESS) //Must Match App's Linker File
    #define D_APP_MaxBlks (2048) //PICMZ:2M/2K=1024, PIC370:512K/512=1024, PIC150:128K/128=1024, PIC170:256K/128=2048

    #endif

     
    i) The archaic file size limit on this form means anything with a pictures must be shared elsewhere, find a zip with more possibly useful stuff here on free DropSend for 7days: (Link will be added after I post to bypass the strict checking)
    http://myaccount.dropsend.om/file/8aa87c0f8d00d04b
     
    j) I do remember doing a process of creating a bootloader project with MHC settings, then disabling those settings to get rid of the generated code, then manually adding back the ld file. This seemed to be needed to put MPLABX into the right "mindset" for either the loader or loaded program, can't remember which. After that you can do custom loader code. Without that you'll have to fight with MHC re-adding files anytime you hit generate. (I have notes somewhere on the details, just can't afford to break my mind state anymore today looking for it).
     
    Paul
     
    (It can be so frustrating trying to post responses in this forum, rejects and length limits for all kinds of unexplained reasons - why not just highlight the rejected line)
    post edited by Paul PortSol - 2019/07/04 08:07:13
    #17
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/04 13:53:31 (permalink)
    0
    Paul PortSol
    Body will be added in after posting due to the strict checks blocking for some weird reason (happens sometimes)
     
    Yes, there is a mess of stuff, and a mess more speedbumps that I only recall piecemeal.
     
    g) Ensure that "loadable" projects have "short names". No idea why but if a project won't link properly with a loadable, rename the target loadable to something short, rebuild it, select it fresh as a loadable, and try again. I've been bitten a few times.
    (Maybe try under 10 char project name length till sure, though I think real cutoff may be over 20char).
     
    h) There are some files that need to be matched to the project's ld file. See attached zip for some examples (mix of possibly useful stuff). I'm busy with my own projects so no time to write a full guide, so you'll have to put in a lot of time to make it work. Even if I wrote up more I'm sure it would be half obsoleted with next microchip update :/
    Search your project for the files with addresses like 0x9d000000, and prepare to adjust those lines to match your customized ld file (I can't remember the name of the original generated file).
     
    Below is an excerpt from one of my header files with the lines modified for the adjusted addresses, and also renamed to match labels in my custom loaded app & bootloader projects.
     

     
     
     
    #define D_BL_Len (0xFF00 - 0x1000) //From btl_mz.ld

    ///AppLoaded: Loaded Application Code for Module normal operation
    #define D_APP_BASE_ADDRESS (0x9d000000) //Exclude 0x18000 (Bootloader+FactFLASH+DataFLASH)
    #define D_APP_LEN (0x200000 - (D_DataFLASH_Reserve))
    #define D_APP_END_ADDRESS (D_APP_BASE_ADDRESS + D_APP_LEN - 1) //Fixed by PIC32 IC
    #define D_APP_RESET_ADDRESS (D_APP_BASE_ADDRESS) //Must Match App's Linker File
    #define D_APP_MaxBlks (2048) //PICMZ:2M/2K=1024, PIC370:512K/512=1024, PIC150:128K/128=1024, PIC170:256K/128=2048

    #endif

     
    i) The archaic file size limit on this form means anything with a pictures must be shared elsewhere, find a zip with more possibly useful stuff here on free DropSend for 7days: (Link will be added after I post to bypass the strict checking)
    http://myaccount.dropsend.om/file/8aa87c0f8d00d04b
     
    j) I do remember doing a process of creating a bootloader project with MHC settings, then disabling those settings to get rid of the generated code, then manually adding back the ld file. This seemed to be needed to put MPLABX into the right "mindset" for either the loader or loaded program, can't remember which. After that you can do custom loader code. Without that you'll have to fight with MHC re-adding files anytime you hit generate. (I have notes somewhere on the details, just can't afford to break my mind state anymore today looking for it).
     
    Paul
     
    (It can be so frustrating trying to post responses in this forum, rejects and length limits for all kinds of unexplained reasons - why not just highlight the rejected line)


    Thank you very much for sharing your information.


    I tried to understand the memory regions of the PIC32MZ, and although it is something I didn't want, I realized that there is no conflict between the bootloader part and the user application, please look at the attached image, in yellow is the application of user and in celeste the bootloader.


    In theory it's fine, the bootloader should jump to the address 0x9D000000 or 0x9D000480 (I'm not sure what KS1 boot is for in the user application), but with both the result is the same.


    I have the idea or that it doesn't jump to the indicated address, or fails to program the user application.


    It occurs to me that at time I must debug the bootloader and try to verify where it jumps after programming the user's app.


    Another idea that occurs to me after the bootloader records the user app is to read all the flash memory of the MCU and verify where and what is recorded in that memory.


    I worked with the PIC32MX and with the bootloader RS232 and Ethernet, I had the same problem but the technical support of MCHP was efficient, I never had to sit down to analyze what was happening.


    Possibly it was not an idea to use the PIC32MZ, maybe I should use SAM32.
     
    #18
    DominusT
    Super Member
    • Total Posts : 1334
    • Reward points : 0
    • Joined: 2005/07/22 08:31:18
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/04 13:56:15 (permalink)
    0

    #19
    Paul PortSol
    Super Member
    • Total Posts : 509
    • Reward points : 0
    • Joined: 2015/07/03 11:52:03
    • Location: Newfoundland, Canada
    • Status: offline
    Re: PIC32MZ bootlader Harmony (USB). Help with the ld file for application. 2019/07/05 04:39:16 (permalink)
    0
    * That memory map doesn't look right, what document did it come from?
     
     
    * See Datasheet PIC32MZ-EF- Family: DS60001320F_20190503.pdf   (Don't use EC parts)
    * Recommend use largest memory PIC in prototypes PIC32MZ2048... so plenty room for development and expansion, then shrink later if necessary for cost.
     
    * Table 4-4 shows map, but table 4-5 shows boot flash detail with lots of restrictions (Most not handled in the sample bootloader projects, and if cross any lines things don't behave nicely - seen in experience).
     
    * There are duplicate/triple access to memory. Code uses virtual addresses, programmers use physical. KSEG macros convert between. Sometimes you need to use two virtual addresses when copying/moving blocks around (not sure but maybe using two separate KSEG pointers allows code execution to be separate from data access, haven't seen a clear explanation so I ended up doing experiments till I got reliable results without crashes).
     
    * Using the wrong virtual block or KSEG macro can lead to a failed copy, or even a corrupted copy - I had some copies that failed compare so I printed out data and it wasn't very consistant about what it copied.
     
    * If having issues I suggest you take the time to either: fully Compare the flashed block to the source block after each flash step (not visually, but with code to catch even a lost bit), print out the source data and actual flashed contents for a few blocks/pages to ensure they are exact. Do a CRC check on source and on target to ensure they match - that's how I caught my issues which were cured by changing my virtual memory pointers around. It took a lot of testing, experimentation, and some "educated" guessing.
     
     Paul
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2019 APG vNext Commercial Version 4.5