Using chipKIT WiFire's bootloader with MPLABX

[hAZ5Cn]

Hi All,

I'm trying to get blinky LED working on my WiFire using MPLABX and the factory boot-loader for programming. I'm using MPLABX 3.35, XC32 1.42, and harmony 1.08.

I found instructions on the chipKIT website about pulling in a linker file from the MPIDE (now arduino) tools but whatever combination of linker files I try seems to segfault xc32-ld. I've used harmony configurator to build my application with boot-loader support (generate a linker file) but this seems to be a different boot-loader implementation and the pic32-prog complains about missing DEVCFG values (as far as I can tell they are linked in the wrong spot) and fails to program even when forced.

Next, I looked for the source for the boot loader hoping to find documentation there about how to make changes to the link to be compatible but, alas, no sauce found.

So, I think at this point I'm looking for instructions on how to modify the default .ld file or for a pre-modified version that I can just use with current versions of MPLABX and XC32. I am guessing someone else has run into this problem before but my google-fu hasn't located their solutions.

Thanks in advance!

 

[campbellCustom]

The Microchip Harmony bootloader basic application has a linker script that is paired with the 'build application linker script' check box in the Harmony Code Configurator. In general over the last several XC32 compiler versions and Harmony versions, the linker scripts have been... in flux... to put it polite... particularly with the MZ products

Do you have a picKit3 or chipKit PGM? If you have one of those, you can just overwrite the factory bootloader, and then burn in the Digilent bootloader hex file if you want it back. If you need a bootloader and you have a programmer you can use the bootloader basic usart that Harmony provides. It may require some modification to call the correct peripherals. You could overwrite the factory hex with the basic bootloader project, and be compatible with the blinky application built in harmony with their special linker script. You'd still need an application that could serve the hex file up over the uart. 

My experience with the ChipKit Pro MX7 has been ok with bouncing back and forth between the factory hex file using MPIDE, as well as using MPLAB X with the onboard debugger for programming. I believe the WiFire doesn't have an onboard debugger, so it may be worth the investment in a picKit3 or the chipKit PGM.

I've noticed while reading up on the PIC32-avrdude-bootloader that they specifically mention not being for factory hex files on Digilent designed products. Perhaps someone on here can offer the source used to generate the factory programmed bootloaders? (I just joined this forum just now to look around and or ask if the source is open)

Getting the memory regions in Harmony to play nice with the unknown linker/application configuration in the factory programming may be very difficult, and require a lot of guessing without the source. Maybe with the Digilent factory linker script you could get the memory regions correct and marry up the correct link locations to your project. You'd still then need to send that hex file over avrdude somehow. 

I've gone through a bit of reading on the Microchip side of things... the Harmony bootloader stuff is mostly still based on an older application note AN1388, which has some mention of linker scripts, and I'm guessing a different protocol for data exchange than the Arduino like stuff (just a guess). The linker script stuff gets pretty deep in the  "MPLAB® Assembler, Linker and Utilities for PIC32 MCUs User’s Guide" 

-IC

[hAZ5Cn]

Thanks for the response.

I have access to an ICD3 which I used to program my blinky LED application. This worked as expected.

Correct, the factory bootloader and the harmony boot loader use different communication protocols. I am wanting to use the stk500v2 protocol implemented by Digilent because the command line programmer tool is available for Linux and because I don't always have access to the ICD3. The AN1388 bootloader that is implemented with the harmony configurator doesn't have a Linux client. Microchip did publish the windows source code along with the application note, but attempting to modify that seems to be just another hazard ridden path.

The pic32prog source on github mentions compatibility with an [USB] HID AN1388 boot loader. I might be able to make that work without hacking up the windows code or cutting myself on the sharp corners in the linker scripts. I think that this will be my experiment for the next time I get my hands on the ICD3.

I've been poking through the linker files provided by XC32, harmony, as well as those in the chipKIT core. I'm really a newb as far as linker scripts go. It is not obvious what changes are necessary for bootloader support and which changes are out of preference or compiler compatibility.

Can Digilent provide the linker script for the boot loader, documentation, or perhaps the source itself, to aid with this endeavor?

[campbellCustom]

I played with this stuff a little bit today. Got all the way deep into staring at the intel hex files.

The WiFire hex file only writes to memory in the 0x1FC0xxxx memory region (config bits are in here at xxxx = FFCO to FFFF)

The basic bootloader application also luckily only writes to the 0x1FC0xxxx region. 

When building an application with the bootloader linker script check box in harmony, the program should mostly reside in 0x1D00xxxx, however it does generate the 0x1FC0FFC0 to 0x1FC0FFFF config bits based on the #pragma settings in system_init.c

Either these #pragma statements can be removed, and thus 'trusting' the config bits used by the bootloader (they don't appear in the hex file in blinky with pragmas commented out) or you can ensure the config bits are exactly the same. Both of these seem a little spooky without the source as you don't know how to set them exactly the same, and you won't know what they're set to if you just remove them from the harmony project.

The ChipKit Pro mx7 has a section with suggested #pragma bit configurations. Not sure why the WiFire datasheet doesn't have it. 

This can get you to the point of a unified hex file. (which will crash your hardware if stuff is setup wrong, such as the jump vector at the end of the bootloader)

Still not sure where the chipKit pre programmed hex will plan to jump to. The basic app uses this:

#define BOOTLOADER_FLASH_BASE_ADDRESS   0x9D000000
#define BOOTLOADER_FLASH_END_ADDRESS    (0x9D000000 + 0x200000 - 1)

It might be useful to look at a hex file that mpide generates to see where the other bootloader is expecting to jump to?

I'm not sure if the forum will pull it but I messily annotated the stuff I looked at. A bit maddening, but could be interesting for reference.

Please note that the annotations make the hex files useless to include with a project

Based on the script they're using for PIC32MX795, Maybe in the blinky app change: 

    kseg0_program_mem  (rx) : ORIGIN = 0x9D000000 + 0x480, LENGTH = 0x200000 - 0x480 /* All C files will be located here */
to

    kseg0_program_mem  (rx) : ORIGIN = 0x9D000000 + 0x1000, LENGTH = 0x200000 - 0x1000 /* All C files will be located here */
 

 

-IC

bootloader_annotations.zip

[JColvin]

Hello,

I have asked some of our applications engineers to see if any of them happen to be familiar with changing a linker script; they'll get back to you here on the forum. Personally, I have found what was labeled as the "common-mz" linker script in the chipKIT Core as well as the bootloader hex file that is pre-loaded onto the WiFIRE (available on the WiFIRE Resource Center), but it seems that you have already located both of these.

Thanks,
JColvin

[Neil Jones]

Hi,

I've traced the execution of the bootcode as supplied in the Rev C WiFIRE using a JTAG debugger and the bootcode jumps to the program flash at 0x9D001000 it jumps from 0x9FC014E0.

The first 0x1000 byte of code look to be reserved for exception handlers and ebase has been set to 0x9D000000 at the point it jumps to application flash.

So build your application with its entry point at 0x9D001000 and exception vectors at 0x9D000000 and it should work.

Cheers,

Neil

 

 

 

[hAZ5Cn]

Hi Neil.

I'll give it a try! Thanks for responding!