Just as an experiment, I tried to replace MPLAB X and friends with Eclipse, GDB and ejtagproxy/pic32prog. I can say it works, and to some point it’s even better than MPLAB, since, for some reason, MPLAB won’t let me do a backtrace. So if the program dies in some processor trap, you can’t go back and see the stack calls. With GDB, you can. I used a PICKit2, but you can do it with a PICkit3. I never tried with the PICkit3 because, apparently, this means a (permanent) downgrade that will make your PK3 become a PK2 (and you will lose ability to program PIC32s from MPLAB).
It will be good if you have a debuggable .hex file for testing. You can create one with MPLAB, just set your configuration bits to a proper value (i.e. set #pragma config DEBUG = ON). You will also need a working MPLAB project directory for testing. It’s much easier that way.
Step by step installation
First of all we need to get ejtagproxy and pic32prog running. There are no debian packages for this but this isn’t terrible since these are stand-alone binaries (no install required).
Official sites: https://code.google.com/p/ejtagproxy/ and https://code.google.com/p/pic32prog/.
apt-get -y install svn libusb1.0-dev libudev-dev svn checkout http://ejtagproxy.googlecode.com/svn/trunk/ ejtagproxy-read-only svn checkout http://pic32prog.googlecode.com/svn/trunk/ pic32prog-read-only cd ejtagproxy-read-only cd ../pic32prog-read-only
If all goes well, ejtagproxy and pic32prog should be built. If not, let me know what the errors are so I can update this post.
If you have any .hex files lying around that you can use to test your PIC32 programming, using pic32prog is dead simple. Just do:
pic32prog file.hex
And that should do it.
GDB
Now on to GDB. Debian’s GDB won’t cut it, since it’s compiled for your machine’s architecture. We need to roll our own (I don’t know hot to make a proper package, so I built from sources. It’s ok – it installs (by default) to /local so it won’t be stepping on your system’s GDB. I will update this post if I find out how to make it “the debian way”. You will need the latest sources from http://ftp.gnu.org/gnu/gdb/.
apt-get build-dep gdb wget http://ftp.gnu.org/gnu/gdb/gdb-7.5.tar.gz tar xvfz gdb-7.5.tar.gz cd gdb-7.5 ./configure --target=mipsel-elf32 make -j4 make install
This will take a good while – GDB pulls quite a few dependencies to build. When it’s finished, you’ll get /usr/local/bin/mipsel-elf32-gdb which is the proper version of GDB targeting the PIC32 MIPS core.
Now we can actually start debugging, just for fun. Start ejtagproxy (just call it with no arguments), step into the project’s directory (the one ending in .X), and run /usr/local/bin/mipsel-elf32-gdb (you’ll need the full path since, if you have another GDB in the system, it may call the wrong one. This will give you an error). Issue: target remote localhost:2000 and you will see activity in ejtagproxy’s window and in your Pickit2. If it says something about __reset, you got it. Press c to make it run. More details here: https://code.google.com/p/ejtagproxy/wiki/Demo_gdb_session.
Microchip XC32 Compiler
No. We cannot do without Microchip’s XC32 as of “yet”. It’s GCC-based, yes, but it’s the compiler that knows the internals of the PIC32 (vectors, pragmas, etc). So, for now, you’re still stuck with it. Get it from http://www.microchip.com/compilers (hint: bottom left) and install. If your system is 64-bit, you’ll also need the 32-bit compatibility libraries. See my previous post for how to install them, or these instructions from Microchip.
Eclipse
Now comes the ugly part. You will need to install Eclipse’s “CDT” plugin (hint: http://www.eclipse.org/cdt/downloads.php). It’s not too difficult, just go into Help, add new software, add the repo, search for CDT, and install. There are quite a few. I have no idea which ones I installed but you can use common sense (I installed the base ones, and the debug ones). I’m using Eclipse 3.8.0 (I think it’s “Juno” but I’m not sure).
Start a new project. Add the files. If you use the Microchip Application Libraries, I recommend you use New > File > Advanced > Link to file in the filesystem, and link them from there.
Go into Project > Properties > C/C++ Build > Settings. This is where you’ll be setting up the XC compiler.
- Replace “Command” (value: gcc) with: /opt/microchip/xc32/v1.20/bin/xc32-gcc.
- Preprocessor: enable “Do not search system directories” (not good for embedded systems!).
- Symbols: Define the symbols you need here (-Dsomething). I use this for HardwareProfile.h when I use the TCP/IP Stack.
- Include: You’ll need to include a few paths. I have the following:
-
- /opt/microchip/xc32/v1.20/lib
- /opt/microchip/xc32/v1.20/pic32mx/include/
- /home/hjf/MAL/Microchip/Include
- /home/hjf/MAL/Microchip
- (the project’s path)
- Optimization: Optimize (-O1) (you can’t use -03 unless you’re in trial or have the paid version).
- Miscellaneous: I don’t know what these are, but I saw that MPLAB puts them, so I put them here: -g -x c -c -mprocessor=32MX795F512L -MMD
- GCC Linker: set command to /opt/microchip/xc32/v1.20/bin/xc32-gcc
- Miscellaneous: same as before. -mprocessor=32MX795F512L -Wl
With this, you should be able to build your project! Hit Ctrl-B and see if it all works! It should. But you won’t get a programmable file. So we go back to Settings > Build Steps > Post Build Steps. Add this command:
/opt/microchip/xc32/v1.20/bin/xc32-bin2hex ${BuildArtifactFilePrefix}${BuildArtifactFileName}
This will generate the .hex file for programming as well.
Tip: You can also add a step to automatically program the pic after building. I leave that as an exercise to the reader.
Setting up GDB+Eclipse
This is the part that gave me the most trouble. You have to do this (and don’t ask questions):
- Right click the project, Debug as, Debug Configurations…
- Double click GDB Hardware Debugger
- at the bottom hit “Select other…”
- change GDB command to: /usr/local/bin/mipsel-elf32-gdb
- Use Remote Target, generic TCP/IP, localhost port 2000 (or the address you’re using).
- In startup, disable reset and delay, halt, and load image (this one seems to program the PIC? I don’t know what it does, but it takes forever).
- go to Common and check the little bug icon (Favorite).
- Hit Debug
Now you’ll get an error, because it’s in __reset. That’s ok! It’s working now. Hit continue, and happy debugging!
You will get errors in the code editor with this configuration, but they will work with the final build. This is because the code editor uses a different compiler. To solve that, go into Project > Properties > C/C++ General > Indexer and set Build configuration for indexer: Use active build configuration. That’ll do it.
P.S.: If ejtagproxy, or your board, seem to lock up, issue pic32prog a few times. This will “reset” the PICkit2.