PIC32MX795F512L BootLoader linker script file transplantation process

I have made study notes based on official materials. If there are any misunderstandings, please point them out.

IDE: MPLAB X IDE v5.35 Compiler MPLAB C32 v2.02
Reference Materials: PIC32 Bootloader (AN1388) and MPLAB Assembler, Linker and Utilities for PIC32 MCUs User's Guide (51833A)
Links are as follows:
PIC32 Bootloader (AN1388)
MPLAB Assembler, Linker and Utilities for PIC32 MCUs User's Guide (51833A)

1. Create a new .txt file in the project directory, then change the suffix to *.ld and add it to the project.
2. Copy the contents of elf32pic32mx.x to the newly created *.ld in the compiler directory MPLAB C32 Suitepic32mxlibldscripts.
3. Replace the 17 lines of INCLUDE procdefs.ld in the copied content in 2 with the contents of the pic32mxlibproc32MX795F512Lprocdefs.ld file in the compiler directory.
4. Copy two copies, one as the linker script for the bootloader and one as the linker script for the app, and then add them to the corresponding projects.
The following figures are the KSEG1 and KSEG0 parts of FIGURE 4-6 in the PIC32MX5XX/6XX/7XX manual.

Linker script content description

KSEG0 is cacheable, KSEG1 is not cacheable.
_ebase_address is consistent with the ORIGIN of exception_mem, which is the interrupt vector address. exception_mem must be aligned on a 4K address.
The ORIGIN of kseg1_boot_mem is consistent with _RESET_ADDR. The C startup code will be mapped into kseg1_boot_mem.
All C files (text and data) are mapped into kseg0_program_mem.
_RESET_ADDR, _BEV_EXCPT_ADDR and _DBG_EXCPT_ADDR are within the range of kseg1_boot_mem.
Some address ranges of the official btl_32MX795F512L_uart.ld overlap, it is recommended to look at btl_32MX795F512L_generic.ld.

Bootloader linker script

The value of kseg1_boot_mem is in the Boot Flash of KSEG1 in the first picture. The ORIGIN of kseg0_boot_mem and exception_mem is in the Boot Flash of KSEG0 in the second picture.
kseg0_program_mem (rx) is in the Program Flash of KSEG0

The linker script of the app

The linker script addresses of the APP are adjacent, such as the official routine code below or the example of the official manual AN1388 below. The value is within the Program Flash range of KSEG0. Note that kseg0_program_mem in the bootloader is within the Program Flash range of KSEG0, and the app should not overlap with it.

kseg0_boot_mem : ORIGIN = 0x9D006000, LENGTH = 0x0 /* ​​This memory region is dummy */ 

exception_mem : ORIGIN = 0x9D006000, LENGTH = 0x1000 /* Interrupt vector table */

kseg1_boot_mem : ORIGIN = (0x9D006000 + 0x1000), LENGTH = 0x490 /* C Startup code */

kseg0_program_mem (rx) : ORIGIN = (0x9D006000 + 0x1000 + 0x490), LENGTH = 0x81000 - (0x6000 + 0x1000 + 0x490) /* All C Files will be located here */ 

Finally, when burning, add the bootloader project to the app's loadables, or add the app to the bootloader to generate a HEX. You can also burn the bootloader first, and then use other methods to burn the app.

ps

The key point is to set the address range according to the size of your project so that the addresses of each area do not overlap. Therefore, it is not necessary to divide it in this way. You can take a look at btl_32MX795F512L_uart.ld.

If you are using PICkit 3, and you have a linker script, then the first default configuration of PICkit 3 is fine. If you select a custom programming location here, and you have a linker script, PICkit 3 will not care about the address in the linker script, and will burn the custom programming location. If you want to use the programmer to customize the location to burn the bootloader and app, it will not work. It seems that everything is erased before burning, and the code burned for the first time is also erased.