chipKIT® Development Platform

Inspired by Arduino™

Can I load MPLAB hex files somehow via bootloader?

Created Mon, 06 Jun 2011 00:21:04 +0000 by rtestardi

rtestardi

Mon, 06 Jun 2011 00:21:04 +0000

Is there any way to load a hex file created with MPLAB (not MPIDE) via the bootloader? With or without MPIDE? I'm looking for a way to do this without a pickit3 (which I have, but which I assume most people don't have).

Also, if this is possible, what linker file should I use in MPLAB to make a "bootloader compatible" hex file? I know the entry point has to be 0x9D001000, and I think I can rewrite any interrupt vectors since the bootloader does not use them.

Thanks for any advice.

-- Rich

Addidis

Mon, 06 Jun 2011 19:36:34 +0000

It is possible, and the answer I got when I asked was

you'd have to use the chipKIT application linker script when you build the app in MPLAB

rtestardi

Mon, 06 Jun 2011 20:12:52 +0000

Thanks! I found the application linker script -- I assume it is: chipKIT-UNO32-application-32MX320F128L.ld

But that only solves half of my problem, I think... I need something to translate a HEX/elf file into the stk500v2 communication protocol which I assume the bootloader is using... Obviously MPIDE can already do this, but I'm not sure how I can coax it into pushing my own HEX file across the wire (vs a HEX file it just built).

I am actually considering writing an Arduino sketch to do this (i.e., accept a HEX file from the serial port and load it to flash), but that seems somewhat circuitous for what I want (not to mention two steps rather than one)...

Any ideas on the protocol conversion? Thanks!

rtestardi

Mon, 06 Jun 2011 20:44:47 +0000

PS just in case someone else is looking for this, it looks like avrdude will do the trick!

[edited command below so as to not mislead anyone not reading further in the thread]

sh-4.1$ ./avrdude -C ../etc/avrdude.conf -c stk500v2 -p pic32-360 -P COM16 -U flash:w:rich.cpp.hex

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude.exe: Device signature = 0x504943 avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed To disable this feature, specify the -D option. avrdude.exe: current erase-rewrite cycle count is -1145324613 (if being tracked) avrdude.exe: erasing chip avrdude.exe: reading input file "rich.cpp.hex" avrdude.exe: input file rich.cpp.hex auto detected as Intel Hex avrdude.exe: writing flash (11536 bytes):

Writing | ################################################## | 100% 2.64s

avrdude.exe: 11536 bytes of flash written avrdude.exe: verifying flash memory against rich.cpp.hex: avrdude.exe: load data flash data from input file rich.cpp.hex: avrdude.exe: input file rich.cpp.hex auto detected as Intel Hex avrdude.exe: input file rich.cpp.hex contains 11536 bytes avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 1.94s

avrdude.exe: verifying ... avrdude.exe: 11536 bytes of flash verified

avrdude.exe: safemode: Fuses OK

avrdude.exe done. Thank you.

sh-4.1$

Mark

Mon, 06 Jun 2011 21:37:34 +0000

Couple more comments

#1, its stk500v2 not stk500, thats the version of the protocol.

#2 As far as the linker goes, it would be best to use the supplied linker. However other linker scripts could work provided that the linker script has to NOT put anything in the bootloader space and leave the top of flash empty.

Mark

rtestardi

Mon, 06 Jun 2011 21:47:24 +0000

Thanks! I actually successfully used the .ld file from the mpide directory in mplab and it worked fine (using the mplab linker). I'll double-check the .hex file I'm generating to make sure I'm not dropping anything in flash anywhere other than the interrupt vectors and code after 0x9d001000. I am able to successfully use mpide after avrdude, which is good, though I know that might not be an exhaustive check of the bootloader dependencies... Thanks -- this is all really cool.

manut

Wed, 16 Jan 2013 16:33:09 +0000

Thanks! I actually successfully used the .ld file from the mpide directory in mplab and it worked fine (using the mplab linker).

Hi Rich,

It seems that's exactly what I'm trying to do! Can you attach a mplab skeleton project with the linker script? If I'm right, you can write code in mplab, create a .hex file with the proper linker script (in order not to override the bootloader flash space) and transfer via avrdude to the board. Isn'it.

I'd like to do this with my uno32 board for 2 reasons:

  • while I'm debugging, I keep using pickit3 for breakpoints and other stuffs
  • I'd like to update my firmware via USB, because the board is in a waterproof case with only USB available (not the icsp connector) and i cannot open it for firmware updates.

Do you know if there is a wiki page or a tutorial on that? (my google searchs aren't very successful on that point...)

Thanks, Manu

Jacob Christ

Mon, 18 Feb 2013 06:23:27 +0000

Rich,

Here is a write up on using a moded version of avrdude gui to upload hex files without mpide.

http://pontech.dyndns.org/pontech/uav100/UAV100-REV-X1-firmware-upgrade%20instructions-2012-03Mar-17.pdf

If you look iin that same dir on the server you will find a zip with the avrdude gui.

Jacob

manut

Wed, 20 Feb 2013 13:06:58 +0000

Hi Rich, It seems that's exactly what I'm trying to do! Can you attach a mplab skeleton project with the linker script? If I'm right, you can write code in mplab, create a .hex file with the proper linker script (in order not to override the bootloader flash space) and transfer via avrdude to the board. Isn'it. I'd like to do this with my uno32 board for 2 reasons:

  • while I'm debugging, I keep using pickit3 for breakpoints and other stuffs
  • I'd like to update my firmware via USB, because the board is in a waterproof case with only USB available (not the icsp connector) and i cannot open it for firmware updates. Do you know if there is a wiki page or a tutorial on that? (my google searchs aren't very successful on that point...) Thanks, Manu

It seems that the linker script file chipKIT-UNO32-application-32MX320F128L.ld doesn't properly work with MPLAB 8.80 and my uno32 board: Avrdude is ok until it checks fuses then I have a bad checksum error. If I uncheck the linker option "don't link startup code", avrdude is ok but I cannot start the application, of course. I will check and compare hex files to see if something is missing, but at the time nothing obvious. I probably have to switch to MPLAB X.

An other path to explore: Maybe it would be easier to learn how to write my code under mpide in plain C rather than writing my application in MPLAB and try to link it with the pre-programmed bootloader. What do you think about that?

l.varani

Mon, 09 Nov 2015 06:40:00 +0000

I try to program a UNO32 with MPLAB X 3.15 Xc32 1.40 linker script chipKIT-application-32MX320F128.ld including chipKIT-application-COMMON.ld Only a main file: void main(void) { } Compile Ok. Avrdude (gently) say: ... avrdude.exe: ERROR: address 0x1fc00490 out of range at line 177 of .... \production.hex ... The production.Hex file contain in the last four lines: ...... :020000041FC01B
:1004800000F89B40C0000000009D1B3C64177B27C8 :10049000020060130000000000C09B4000F81B40F9 :0C04A000C00000001F000042000000002F

The problem is with line 0490 why this code at these addresses and what mean? have an idea where the problem comes? luciano

majenko

Mon, 09 Nov 2015 11:17:56 +0000

Which version of avrdude are you using?

l34nder

Thu, 03 Dec 2015 23:03:32 +0000

Which version of avrdude are you using?

I have the same problem. MPLAB X 3.15, XC1.40, Uno32 board

I have tried three versions of avrdude and also tried pic32prog.

avrdude: Version 5.8cvs, compiled on Jan 15 2010 at 17:27:01
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0x504943
avrdude: NOTE: FLASH memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: current erase-rewrite cycle count is -1145324613 (if being tracked)
avrdude: erasing chip
avrdude: reading input file "dist/XC32_PIC32MX320F128H/production/pic32mx_c_template_1.X.production.hex"
avrdude: input file dist/XC32_PIC32MX320F128H/production/pic32mx_c_template_1.X.production.hex auto detected as Intel Hex
avrdude: ERROR: address 0xc00490 out of range at line 168 of dist/XC32_PIC32MX320F128H/production/pic32mx_c_template_1.X.production.hex

Then I tested avrdude 5.11 and get exactly same ERROR as with 5.8. With avrdude 6.0.1 (from Arduino IDE 1.6.5):

avrdude: Version 6.0.1, compiled on Apr 14 2015 at 16:30:25
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/Applications/microchip/mplabx/v3.15/mplab_ide.app/Contents/Resources/mplab_ide/bin/avrdude.conf"
avrdude: error at /Applications/microchip/mplabx/v3.15/mplab_ide.app/Contents/Resources/mplab_ide/bin/avrdude.conf:318: programmer type must be written as "id_type"

Seems that avrdude.conf need to be updated with something.

Final test: I copied pic32prog from chipkit-core. pic32prog is complaining that the hex file is missing DEVCFG. The are defined in configuration_bits.c and is compiled and linked as far as I can see.

User defined post-build step: [/Applications/microchip/mplabx/v3.15/mplab_ide.app/Contents/Resources/mplab_ide/bin/pic32prog -d /dev/cu.usbserial-AJV9JXNA -b 115200 dist/XC32_PIC32MX320F128H/production/pic32mx_c_template_1.X.production.hex ]
Programmer for Microchip PIC32 microcontrollers, Version 2.0.185
    Copyright: (C) 2011-2015 Serge Vakulenko
      Adapter: STK500v2 Bootloader
 Program area: 1d000000-1d1fffff
    Processor: Bootloader
 Flash memory: 2048 kbytes
  Boot memory: 80 kbytes
         Data: 3192 bytes
DEVCFG values are missing -- check your HEX file!

l34nder

Sat, 05 Dec 2015 11:36:47 +0000

Final test: I copied pic32prog from chipkit-core. pic32prog is complaining that the hex file is missing DEVCFG. The are defined in configuration_bits.c and is compiled and linked as far as I can see.

User defined post-build step: [/Applications/microchip/mplabx/v3.15/mplab_ide.app/Contents/Resources/mplab_ide/bin/pic32prog -d /dev/cu.usbserial-AJV9JXNA -b 115200 dist/XC32_PIC32MX320F128H/production/pic32mx_c_template_1.X.production.hex ]
Programmer for Microchip PIC32 microcontrollers, Version 2.0.185
Copyright: (C) 2011-2015 Serge Vakulenko
Adapter: STK500v2 Bootloader
Program area: 1d000000-1d1fffff
Processor: Bootloader
Flash memory: 2048 kbytes
Boot memory: 80 kbytes
Data: 3192 bytes
DEVCFG values are missing -- check your HEX file!

I thought that pic32prog would not need DEVCFG values. I've tried uploading other hex files generated by chipKit-core and from a freestanding environment I have. Hex files from both environments are missing config data (I've verified it in MPLAB_IPE) and they upload just fine with pic32prog.

Next I tried to use the ld scripts from chipkit-core (2015-10-18). I can compile and link without errors but I get the same error when I try to upload the generated hex file with pic32prog, DEVCFG values missing. Yes they are missing, but they should not be in there.

Any ideas what is wrong here? Is pic32prog thinking it is uploading a bootloader or similar and does some additional checks if hex file include config data?

majenko

Sat, 05 Dec 2015 11:38:54 +0000

Maybe serge has added some extra checks and forgotten that when using a bootooader those checks are irrelevant. I will check the sources. Serge does seem to overlook the bootloader sometimes...

Sent from my SM-T555 using Tapatalk

majenko

Sat, 05 Dec 2015 11:46:38 +0000

It looks like if there is anything at all being written to the boot flash area then config bits are required, whether or not the area of the boot you are writing coincides with the config bits page. I'm not sure if there really should be anything being written to that area by your compilation, I'll have to check a sample output from a normal UECIDE compilation.

Sent from my SM-T555 using Tapatalk

majenko

Sat, 05 Dec 2015 12:07:08 +0000

I can see no reason for anything to be written to the boot flash area, unless you aren't using the right linker scripts while compiling. If you don't, then code will be put in the boot area and pic32prog will most definitely complain.

l34nder

Sat, 05 Dec 2015 15:07:03 +0000

When I looked in the source code of pic32prog I could see that boot_used must have been set. I don't know why yet. I've used the linker scripts from MPIDE/chipkit-core I thought that would ensure that program code goes to the right area. I verified that my provided linker script was really used by introducing an error in the common file.

The MPLAB X makefile references the link script:

dist/${CND_CONF}/${IMAGE_TYPE}/pic32mx_c_template_1.X.${IMAGE_TYPE}.${OUTPUT_SUFFIX}: ${OBJECTFILES}  nbproject/Makefile-${CND_CONF}.mk   chipKIT-application-32MX320F128.ld

The c template is only calling SYSTEMConfig() and INTConfigureSystem(). That's it.

I can provide map file, hex file, linker scripts, the simple c-code as a zip file if that helps.

majenko

Sat, 05 Dec 2015 17:34:09 +0000

A hex file would be useful...