pic32 bootloader linker script

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
Hello All,
A while since i have posted..still, here goes..
I am trying to implement a pic32 bootloader, and have been looking at AN1388 application note.
I have also been looking at the source code for it, however i have been getting a little confused with the linker script.
I would like to put the bootloader in the 12k memory specially for bootloaders.
(oh im using PIC32MX460F512L) however, the linker advice mentioned in example 11 and example 12 on the application note is confusing me slightly, as it says the app flash end address need to be at the end of the total area.. you can see where im struggling, especially with the definition of kseg0, kseg1 and other parts.
This also needs to generate an app linker script ( i assume) to know where to map the application? not sure.
Any help is much appreciated.. id like to figure it all out as opposed to just getting an answer as i can imagine this being needed for future processors and projects!
Many thanks in advance
Useful Files:
AN1388
PIC32MX460F512L
 

ErnieM

Joined Apr 24, 2011
8,377
Does your entire bootloader fit into the 12K bootloader area? If so there *should* be a standard script for that.

I did a fair amount of bootloader work with that same processor, in mine an app could leave a "magic number" in a certain RAM location that would invoke a bootloader. The loader would read another location to get a file name and read the source from an SD disk. The absolutely hardest part of this was getting the linker scripts working.

Scripts. Plural. The bootloader and the application have different, complementary scripts as the app code needs to avoid loading over the boot code.

I did my work back in 9/2011 using C32 v2.02 and have long forgotten all the fine details of linker script manipulation. I did learn it from that app note and the “MPLAB® Assembler, Linker and Utilities for PIC32 MCUs User’s Guide.”

You should slide over the the microchip.com forums and ask them there. Someone probably did this last week and has an answer ready.

Do tell them in post #1 what version of the compiler you are using... there have been some huge difference in various versions requiring different linker scripts.
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
it will fit in the 12k:p i havent written it yet, but i was intending to optimise. it only needs basic functionality.
i shall have to write two linkers, least i have that confirmed!
i dont quite understand the purpose of your magic number, whether thats as a checksum for the hexfile? i dont know..?
Cheers Ernie :)
 

ErnieM

Joined Apr 24, 2011
8,377
The bootloading scheme I used (as do the Microchip bootloaders I've studied) all start by running the bootloader. The BL looks for some flag to see if it needs to either do a load, or just pass off to the application code. The examples I've seen use a physical button on a pin to make this flag. My "magic number" is used as that flag.

Good luck getting the BL to fit into 12K: You usually need the full compiler ($$$) with all the optimizations turned on to get that. I just use the freebie version so my code is large so my BL doesn't fit into the BL area, it sits at the beginning of the app code area. Since I have full file system (albeit striped down with just the ability to read data) my code never had a chance to fit there.

Cheers!
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
i was intending to write the bootloader intentionally with microchip MDD filesystem, then implement the Petit FatFS which is around 2k-4k prog mem and under 50bytes RAM..
so lightweight its worth it.
How do i get it to place the bootloader in memory then? just write a linker for the boot mem in the pic?
ahh yes, i see what you mean by the magic number, like you say the switch.

In comparison:
Petit FS, with write and read and directories is reportedly around 2.5-3K prog mem,
MDD FS, reports around 27kbytes for the same features.
(just to quantify and compare them, i know the MDD FS makes things very simple for the user and i know you are a big fan of the system)
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,377
How do i get it to place the bootloader in memory then? just write a linker for the boot mem in the pic?
The bootloader loads in with a PICKit (3) or an ICD... I use an ICD3 on PIC32's.

If you are very clever you can build both the Bl and the app inside one project and load them all in one go... but I'm not that clever so I would load the BL by itself then get it to load my app code.

I do have a "backdoor" button that when depressed loads a certain application; that app is called "ProgMan" (for those who remember Windows 3) which displays all the hex files currently on the SD card and lets you use a drop down box to select one. Helps much to have a graphic touchscreen to do that <grin>. Also the USB is active to make the PIC work as an SD card drive so you can access the SD contents from a PC.

Petite FS always looked good to me, I just never spent the time to pull it apart and make it work in a conventional Microchip C format (with a HardwareProfile.h to define what hardware I expect to use).
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
well i intend to use it, so i will make sure i post it.. is there a repository for code on here?
i will post the bootloader code, linker, and the bootloader will implement USB on the petite Fat system... theres some objectives for ya! in additon to all the other uni work.. *sigh*
sorry i should have been clearer with my question, i mean, with regards to the linker, how do i get the bootloader into the 12k?
im reading through the app notes still but its the main question i have, just trying to understand the app_address ksegx_boot_ etc bits.
//EDIT//// (more of an addition, but i didnt want to create a new reply)////
ok, long evening spending multiple hours.. i think i get the bootloader, i found an old version of the AN1388 app note, which explains and works through a sample, and it defines certain things i felt unclear in what i was looking at, so wahey.. at some point ill be able to test that.. by which point ill have forgotten what i had done..

in addition to this, i have been looking at the Petit Fat system, and in order to use the system i need to write a disk_initialise, disk_readp and disk_writep function (though i wont be using the write..) i have a USB diskio for the full FATFS, but the petit implements another variable passed into the function, offset.. (see the pages..and i can upload the diskio file i have if needed).. i dont know how to do this, im not sure if it is needed, and could therefore be added in the prototype and brackets but just not used in the function..? sure i could test it, but id like to wrap my head round why i need it (probably something to do with reduced ram size and prog mem) and how to solve the problem.
//end edit.. and conveniently, bed time..//
 
Last edited:

ErnieM

Joined Apr 24, 2011
8,377
The following will only apply if you are using the non-X version of the C32 compiler (not the XC32). Some things look the same, some things seem to have changed.

That's part of the fun of using Microchip: every year or two the tools change and all your code breaks. Their code too, the examples in the AN1388 will probably not build clean either.

The closest link script I found in the examples is uart_btl_ex16.ld, which is the only one to state "Mapping Note: The entire bootloader is mapped into the Boot Flash."

From memory I recall something like C32 V2.0 separated the linker scripts into 2 sections in separate files, one full of things that don't change, one with the goodies. If you call the goodies "procdefs.ld" and place it in your project folder the linker finds it automatically...(if you have it somewhere else you can include that path in build options).

Anyway, I took the link script I thought was correct and edited it to fit the V2.0 style:

Rich (BB code):
/*************************************************************************
 * Bootloader linker script, untried !!!!!!!!!!
 * Mapping Note: The entire bootloader is mapped into the Boot Flash.
 * Adapted from uart_btl_ex16.ld
 * EJM  1/15-13                                               
 *************************************************************************/

/*************************************************************************
 * Processor-specific object file.  Contains SFR definitions.
 *************************************************************************/
INPUT("processor.o")

/*************************************************************************
 * For interrupt vector handling
 *************************************************************************/
PROVIDE(_vector_spacing = 0x00000001);
_ebase_address = 0x9FC01000;

/*************************************************************************
 * Memory Address Equates
 *************************************************************************/
_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;

/*************************************************************************
 * 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 = 0x9FC00490, LENGTH = 0x1AF0
  kseg0_boot_mem             : ORIGIN = 0x9FC00020, LENGTH = 0x350
  exception_mem              : ORIGIN = 0x9FC01E00, LENGTH = 0x200 /* Dummy IVT to fool the linker. This code uses no ISR*/
  kseg1_boot_mem             : ORIGIN = 0xBFC00000, LENGTH = 0x490
  debug_exec_mem             : ORIGIN = 0xBFC02000, LENGTH = 0xFF0
  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 = 0x8000
  sfrs                       : ORIGIN = 0xBF800000, LENGTH = 0x2000
  configsfrs                 : ORIGIN = 0xBFC02FF0, LENGTH = 0x10
}

SECTIONS
{
  .config_BFC02FF0 : {
    KEEP(*(.config_BFC02FF0))
  } > config3
  .config_BFC02FF4 : {
    KEEP(*(.config_BFC02FF4))
  } > config2
  .config_BFC02FF8 : {
    KEEP(*(.config_BFC02FF8))
  } > config1
  .config_BFC02FFC : {
    KEEP(*(.config_BFC02FFC))
  } > config0
}
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
why did you have to fool the linker with the IVT?
also.. why give it a length of 200? why not 0? or at all..? does the compiler need it?
 

ErnieM

Joined Apr 24, 2011
8,377
I dunno... I did not write this linker script, I found it in the examples. Microchip's coders did that. I extracted the part that would work with the version 2.0 C32 linker.

Do say what version of the compiler you are going to use? Is it C32 or XC32?
 

Thread Starter

chrisw1990

Joined Oct 22, 2011
551
i was going to stick to C32, im not convinced the XC compilers are really that great atm, my experience recently with XC8 was enough for me to stick with the older compilers for the time being!
it didnt like the linker and interrupt file i required to operate in C18.. though time constraints really limited my efforts in problem solving this!
have you used XC32? and mplab X? my colleagues and i have avoided X for sometime now, while it has nice features i think it needs polishing to finally become a great piece of software..bugless :)
 

ErnieM

Joined Apr 24, 2011
8,377
For PIC32 I use C32 v2-something. I went thru weeks of fits upgrading from v1 to 2 when lots of code broke, and I tossed in a MAL upgrade at the same time that broke some GOL code I needed. I want to keep that static thank you, so no upgrade at this time.

I don't even want to install XC32 as I worry it will break something on C32.

I'm currently using XC8 for the tiny devices, but there was a rough path when it went from about v1.00 to 1.01 where pointers fell to crap. Seems better now at least for what I need it for. I'm ascared to change from C18 for PIC18 stuff, I don't want any of that code to break.
 
Top