chipKIT® Development Platform

Inspired by Arduino™

Overriding Chipkit's linker settings

Created Mon, 05 Jun 2017 14:35:21 +0000 by The_YongGrand


Mon, 05 Jun 2017 14:35:21 +0000


I'm creating a new Chipkit platform for a custom board, and I have managed to have the pic32prog to upload the application hex with the "an1388" flag.

However, the linker in the Chipkit platform (Arduino IDE) ended up linking at least another linker script "chipKIT-BL-mega.ld" or "chipKIT-application-COMMON.ld" while the linker script I supplied in the "Build Variant" folder contains the entire stuff required to fully link into the complete hex file.

Note that I'm not using the Chipkit's bootloader - I used the Harmony's bootloader instead on the custom board, and then I used the Harmony's generated linker file "app_mz.ld" (application linker script) specially for loading into the custom board.

In MPLAB X IDE, it compiles the entire thing well with only the "app_mz.ld" included.

The problem with the Chipkit platform is, it everytime includes the default "chipKIT-BL-mega.ld" and the "chipKIT-application-COMMON.ld" into the linking and also accidentally combining it with the "app_mz.ld" which I put them into the "Built Variant" folder, and caused link errors such as:

"warning: memory region kseg0_eeprom_mem' not declared" "warning: memory region configsfrs' not declared" "warning: memory region kseg1_data_mem' not declared" "section .init' will not fit in region `kseg0_program_mem'"

I tried looking around whether I can have a seperate option to bypass including the default linker directives, but I can't find that. I got a feeling that there must be a switch or whatever to override this option.

Any way for the Chipkit platform to just do away with one main linker file chosen by user instead of accidentally combining the default ones? :)


Mon, 05 Jun 2017 15:33:48 +0000

The whole chipKIT build environment is geared around having two linker scripts - the "common" one for the chip family, and the "board" one that is specific to your board.

You can probably "fool" it by providing a blank "common" linker script, or having your linker script as the "common" one and providing a blank "board" linker script. You will need to name them both in the boards.txt file - for instance the WiFire has:


So you could have:


You may also have to have your "common" file as a relative path name to the "core" folder, since it's included as:

-T "{build.ldscript.path}/{ldscript}" -T "{build.core.path}/{ldcommon}"

So maybe


might be what you want (I am not sure).

The Arduino IDE isn't that great at being flexible.

No guarantees it'll work, and you may find other things are then broken - such as EEPROM emulation - which relies on specific things defined in the linker scripts that Harmony doesn't know about.

Maybe you should spend some time making a proper "board" linker script (it doesn't have much in it, mainly memory assignments) out of your harmony one to fit in with the existing chipKIT structure...

Also note that we do not currently have any USB support in chipKIT for the MZ chips yet (it's something I am working on by trying to integrate portions of Harmony), so you won't be able to use the USB interface.


Wed, 07 Jun 2017 02:29:10 +0000

Hello majenko, thanks for the reply. I followed what you suggested on the dummy linker file, it did link halfway through, but it shouts something like "reset vectors are overlapping other codes". Since I'm not at my desk now, I will show you the exact error later when I'm at home.

I believe that I may need to modify the *.ld script as you have mentioned earlier as some of the addresses/vectors in the Harmony's ld script isn't same as the one in the Chipkit.


Fri, 16 Jun 2017 14:00:12 +0000

Hey, an update! After messing around with the "app_mz.ld" and tallying the generated *.map file with the chipkit and mine, I get it to work with the AN1388 Harmony bootloader. Even the pic32prog works within a reach!

The tedious part was to debug the bootloader + app. When I started, the linker went placing the .reset vector in the wrong place and linker errors were all over it (overlapping regions). With trial and errors, to test the app, I had to sideload the *.hex and the *.elf file into the MPLAB XC32 debugger (under "loadables"). Over the time, I discover many more errors, like the funny moment where the startup code (.init) accidently wandered into an "empty zone" while side-stepping, triggering a "Reserved instruction" exception. [This is due to me not adding the extra "crtbegin.o", "crtend.o" and "crtn.o" in the linker script] Every error I detect, I isolated and fixed them one by one, and finally that "Hello World" LED blink works afterwards.

However all is not done as I'm not sure if the interrupt vectors are compiled and linked right into their respective places. I have to also test the remaining peripherals like SPI and I2C to see if it actually works from there. :D