• AVR Freaks

Hot!Linking PIC32 application for use with a bootloader

Author
thn
New Member
  • Total Posts : 3
  • Reward points : 0
  • Joined: 2018/09/02 03:59:27
  • Location: 0
  • Status: offline
2018/09/06 03:30:04 (permalink)
0

Linking PIC32 application for use with a bootloader

Hi
 
I'm trying to run an application from a bootloader on a PIC32MX470 using the AN1388 bootloader example.
 
I extracted the documentation from the AN:
      Rules:
      - The memory regions kseg0_program_mem, kseg0_boot_mem, exception_mem
        and kseg1_boot_mem of the application linker script must fall with
        in \ref APP_FLASH_BASE_ADDRESS and \ref APP_FLASH_END_ADDRESS
      - The base address and end address must align on 4K address boundary
      - Set \ref APP_FLASH_BASE_ADDRESS to \c _RESET_ADDR value of
        application linker script.

      Note:
      The BMXPFMSZ is a special function register (sfr). It contains the
      amount of Flash memory available on the device. The Flash memory
      begins at address \c 0x9D000000 on most PIC32 CPUs.

 
The example in the AN1388 included linker script modifications :
      # _ebase_address value must be same as the ORIGIN value of
      # exception_mem (see below)
      _ebase_address = 0x9D000000;

      # Equate _RESET_ADDR to the ORIGIN value of kseg1_boot_mem (see below)
      _RESET_ADDR = (0x9D000000 + 0x1000 + 0x970);

      # Map _BEV_EXCPT_ADDR and _DBG_EXCPT_ADDR in to kseg1_boot_mem (see
      # below)
      # - Place _BEV_EXCPT_ADDR at an offset of 0x380 to _RESET_ADDR
      # - Place _DBG_EXCPT_ADDR at an offset of 0x480 to _RESET_ADDR
      _BEV_EXCPT_ADDR = (0x9D000000 + 0x1000 + 0x970 + 0x380);
      _DBG_EXCPT_ADDR = (0x9D000000 + 0x1000 + 0x970 + 0x480);

      MEMORY
      {
              # IVT is mapped into the exception_mem. ORIGIN value of
              # exception_mem must align with 4K address boundary. Keep the
              # default value for the length
              exception_mem : ORIGIN = 0x9D000000, LENGTH = 0x1000

              # Place kseg0_boot_mem adjacent to exception_mem. Keep the
              # default value for the length
              kseg0_boot_mem : ORIGIN = (0x9D000000 + 0x1000), LENGTH = 0x970

              # C Start-up code is mapped into kseg1_boot_mem. Place
              # kseg1_boot_mem adjacent to kseg0_boot_mem. Keep the default
              # value for the length
              kseg1_boot_mem :
                      ORIGIN = (0x9D000000 + 0x1000 + 0x970), LENGTH = 0x490

              # All C files (Text and Data) are mapped into kseg0_program_mem.
              # Place kseg0_program_mem adjacent to kseg1_boot_mem. Change the
              # length of kseg0_program_mem as required. In this example,
              # 512 KB Flash size is shrunk as follows:
              kseg0_program_mem (rx) :
                      ORIGIN = (0x9D000000 + 0x1000 + 0x970 + 0x490),
                      LENGTH = (0x80000 - (0x1000 + 0x970 + 0x490))

      ...

      }

 
So I got the .ld script, added it to my project and modified those lines just as the documentation told be :
--- a/ezcontrol-app.ld
+++ b/ezcontrol-app.ld

-_ebase_address = 0x9FC01000;
+_ebase_address = 0x9D020000; /* XXX --- TUNABLE */

-_RESET_ADDR = 0xBFC00000;
-_BEV_EXCPT_ADDR = 0xBFC00380;
-_DBG_EXCPT_ADDR = 0xBFC00480;
+_RESET_ADDR = 0x9D021970; /* XXX --- TUNABLE */
+_BEV_EXCPT_ADDR = 0x9D021CF0; /* XXX --- TUNABLE */
+_DBG_EXCPT_ADDR = 0x9D021DF0; /* XXX --- TUNABLE */
 _DBG_CODE_ADDR = 0xBFC02000;
 _DBG_CODE_SIZE = 0xFF0;
 _GEN_EXCPT_ADDR = _ebase_address + 0x180;

 MEMORY
 {
- kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x80000
- kseg0_boot_mem : ORIGIN = 0x9FC00490, LENGTH = 0x970
- exception_mem : ORIGIN = 0x9FC01000, LENGTH = 0x1000
- kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490
+ /* XXX --- START OF TUNABLES LIST */
+ /* All C Files will be located here */
+ kseg0_program_mem (rx) : ORIGIN = 0x9D021E00, LENGTH = 0x5E200
+ /* This memory region is dummy */
+ kseg0_boot_mem : ORIGIN = 0x9D021000, LENGTH = 0x970
+ /* Interrupt vector table */
+ exception_mem : ORIGIN = 0x9D020000, LENGTH = 0x1000
+ /* C Startup code */
+ kseg1_boot_mem : ORIGIN = 0x9D021970, LENGTH = 0x490
+ /* XXX --- END OF TUNABLES LIST */

 
However it didn't help to boot the application. So I checked the provided examples for linker scripts and, as none were available for my model, I checked the differences between the example's PIC32MX460 and the toolchain's one :
--- p32MX460F512L.ld /* Default linker script, for normal executables */
+++ btl_32MX460F512L_generic_unix.ld /* Example linker script */

-_ebase_address = 0x9FC01000;
+_ebase_address = 0x9FC01000;

-_RESET_ADDR = 0xBFC00000;
-_BEV_EXCPT_ADDR = 0xBFC00380;
-_DBG_EXCPT_ADDR = 0xBFC00480;
-_DBG_CODE_ADDR = 0xBFC02000;
-_DBG_CODE_SIZE = 0xFF0;
-_GEN_EXCPT_ADDR = _ebase_address + 0x180;
+_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;

- kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x80000
- kseg0_boot_mem : ORIGIN = 0x9FC00490, LENGTH = 0x970
- exception_mem : ORIGIN = 0x9FC01000, LENGTH = 0x1000
- kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490
+ kseg0_program_mem (rx) : ORIGIN = 0x9D000000, LENGTH = 0x6000 /* 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 */
+ kseg1_boot_mem : ORIGIN = 0xBFC00000, LENGTH = 0x490 /* C Startup code */

 
Obviously there weren't much differences on the ebase_address, RESET address and BEV exceptions address... Putting these values into my own linker script did not help either...
 
Can someone tell me what I'm doing wrong ?
 
Thank you.
#1

4 Replies Related Threads

    Jim Nickerson
    User 452
    • Total Posts : 6187
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: Linking PIC32 application for use with a bootloader 2018/09/06 05:40:25 (permalink)
    0
    Maybe you could run the bootloader in debug mode and watch what happens
    #2
    thn
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2018/09/02 03:59:27
    • Location: 0
    • Status: offline
    Re: Linking PIC32 application for use with a bootloader 2018/09/07 05:38:57 (permalink)
    0
    I forgot to mention I did that too. But the debugger could not access (don't know why) the part of the code for the jump to the application.
    #3
    Jim Nickerson
    User 452
    • Total Posts : 6187
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: offline
    Re: Linking PIC32 application for use with a bootloader 2018/09/07 06:07:03 (permalink)
    0
    Unless the application project is a loadable as part of the bootloader project it is quite true it is very difficult to follow the jump from the bootloader to the application.
    Even so I have always been able to follow the bootloader code up to the point where it jumps to the application and verify the location is what I expect.
    #4
    thn
    New Member
    • Total Posts : 3
    • Reward points : 0
    • Joined: 2018/09/02 03:59:27
    • Location: 0
    • Status: offline
    Re: Linking PIC32 application for use with a bootloader 2018/10/14 01:27:01 (permalink)
    0
    Sorry for the delay, I was away on vacation.
     
    Unfortunately mplab-x integrated  does not allow me to see the jump destination address (other than the hard-coded macro value).
     
    But my main worry is whetther I put in the LD script the right values for the differents sections. Indeed, moving _ebase_address from 0x9fc01000 to 0x9d-something is a great leap. How come is it not straightforward to place an app in the Flash :) ? Well, just starting with the size of the application, the size of the bootloader and the size of the Flash memory, it should be relatively easy to put everything into place.
     
    That's why I posted a help message here : are, at least, my sections addresses right ?
     
    I've seen some code where the _ebase_address is 0x9D000000 -- I suppose this is because the bootloader is so small it can fit in the boot memory. Mine is 0x9D020000 because I made the bootloader way bigger (needed some user information on an LCD screen, USB key handling and stuff like that).
     
    Am I all wrong ?
    #5
    Jump to:
    © 2019 APG vNext Commercial Version 4.5