Created Sat, 06 Sep 2014 19:09:49 +0000 by peplin
Sat, 06 Sep 2014 19:09:49 +0000
A little over a year ago, I contributed support for compiling for the chipKIT to the Arduino-Makefile project. I've been happily using it to compile the chipKIT firmware for the OpenXC OBD vehicle interface firmware since then.
Lately we've been having trouble with some 32-bit support libraries in Ubuntu, so I started looking into updating out build process to use the newer releases of MPIDE. We are currently on mpide-0023-linux32-20130817-test.
Short summary: it doesn't work, yet. My question: is there a detailed description of the changes in the build process over the various releases?
I found that I now need to define _image_header_info, but I'm not really sure what the values should be and I'd like to not have to auto-generate code during the Makefile build process.
I also noticed that <algorithm> is gone :/.
Finally, I got it to compile, but avrdude rejects the .hex file:
avrdude: Device signature = 0x504943
avrdude: current erase-rewrite cycle count is -1145324613 (if being tracked)
avrdude: reading input file "build/CHIPKIT/vi-firmware-CHIPKIT.hex"
avrdude: ERROR: address 0x9fc004a0 out of range at line 14138 of build/CHIPKIT/vi-firmware-CHIPKIT.hex
avrdude: read from file 'build/CHIPKIT/vi-firmware-CHIPKIT.hex' failed
Anything I should look into or read up on? Thanks!
Sat, 06 Sep 2014 21:01:11 +0000
I have it compiling now, but avrdude still doesn't like the addresses in the hex file. I think the root cause has something to do with this error I get when linking:
/home/peplin/dev/openxc/vi-firmware/dependencies/mpide/hardware/pic32/compiler/pic32-tools/bin/../lib/gcc/pic32mx/4.5.2/../../../../pic32mx/bin/ld: warning: cannot find entry symbol _reset; defaulting to 9d000000
So the link defaults to the address 0x9d000000 for the entry point, and then avrdude rejects it:
avrdude: ERROR: address 0x9fc01208 out of range at line 23 of build-mega_pic32/BlinkChipKIT.hex
Where is _reset supposed to be defined?
Sat, 06 Sep 2014 21:36:09 +0000
Getting closer!
These three commits got it compiling, and I can flash the Blink example with avrdude:
https://github.com/peplin/Arduino-Makefile/commit/321430baed3bbca4d2e6d69d446cc46ff0ed551a
https://github.com/peplin/Arduino-Makefile/commit/6f9e04c37df1f9a1e735c3438da8c967bdc10f25
https://github.com/peplin/Arduino-Makefile/commit/6ece43c6f43e0e2f2bd8c9627ce82d25ecfb4b16
However it doesn't run, no blinking. There's still a difference between the hex file generated by the MPIDE and Arduino-Makefile, so I'll continue to compare the flags.
Mon, 08 Sep 2014 22:10:57 +0000
It sounds to me like you may have a linker script issue. The _image_header_info is defined in chipKIT-application-COMMON.ld which must be linked along with the chip specific linker script.
Your best bet would be to do a verbose compile (or run MPIDE from a terminal / command prompt depending on your OS) and examine the commands that get executed and compare them to the commands that get executed by your Makefile. It can be an onerous task looking for differences, but that's really the best way to learn what is happening.
Mon, 08 Sep 2014 22:16:08 +0000
Also, if you are using the MZ compatible compiler (gcc version 4.5.2 chipKIT Compiler for PIC32 MCUs v1.31 (chipKIT)) and the crti.S file doesn't get placed in the archive (if you're using an archive?) as crti.S.o (that precise filename, and not crti.o) then there is a bug that causes the files to get linked in the wrong way, and during startup a bad address exception is raised, which basically causes it to crash.
So to clarify, crti.S must be compiled as crti.S.o for the latest compiler to work. Jason's looking into the problem at the moment (amongst other things).
Tue, 09 Sep 2014 13:07:13 +0000
Thanks majenko - I am using an archive, and I am not adding crti.S as crt.S.o, but instead as crti.o as you mentioned. I'll make the change and give it a try.
Fri, 19 Sep 2014 01:48:34 +0000
That was it - it's working again now. Thanks!
https://github.com/sudar/Arduino-Makefile/pull/256
Fri, 19 Sep 2014 09:13:10 +0000
Excellent. I had to add some bad hacks into UECIDE (at least temporarily) to work around that very same problem.