chipKIT® Development Platform

Inspired by Arduino™

A new and easier way to debug chipKIT sketches in MPLAB

Created Thu, 13 Oct 2011 21:01:04 +0000 by KeithV

KeithV

Thu, 13 Oct 2011 21:01:04 +0000

As I was developing the Network Shield libraries, debugging sketches was an absolute necessity. Some of you have been using a procedure I outlined in “Debugging chipKIT with MPLAB.pdf”. While this allowed for the debugging of sketches which is a tremendous help, the process is clumsy at best; and packed with pitfalls. As I became more familiar with MPIDE and MPLAB I concluded there had to be better way. With a lot of help from a friend at Microchip we were able to create a much better debug process. In short what we are doing is having MPIDE build a debug image in the same way MPLAB 8 would have, then importing that image into MPLAB 8 and debugging it as if MPLAB built the image. Here we are using MPIDE as a replacement compiler / linker for MPLAB. As a result, MPLAB is debugging as it usually does and things just work better.

Attached to this posting is a document (“Debugging chipKIT MPIDE Sketches with MPLAP.pdf” -- zipped) describing the process and a .zip file (“MPIDE_MPLAB_Debug.zip”) that you will have to uses to include some new linker scripts in MPIDE. This process will replace you boards.txt, but it only adds 2 new boards to your MPIDE environment, it does not modify existing board entries (well with the exception of fixing a bug in the “mega_pic32.board” entry). If you rather, you can just cut and paste the 2 new entries into your existing boards.txt Read the document first, it will tell you how to install and what all is involved.

While I have been using this process with great success for a few weeks now, this is my first attempt to formalize the process. So this is all “hot off the presses”. Please give me your comments / corrections. I do not know if this will ever be rolled into MPIDE or not, I think a lot of that depends on what people think of it.

UPDATE as of 10/28/2011:

I found a bug with the clock speeds when debugging. I inadvertently set the peripheral clock div to 8 instead of 1 so when debugging your clock timers were running 8 times slower than they should. Replace your linker scripts with the new ones updated and attached to this posting.

I bundled both the new and old debug documents in the one attached zip file. PLEASE READ the “Debugging chipKIT MPIDE Sketches with MPLAP.pdf” before attempting to debug.

I also included a crude video of debugging the sample Blink sketch with an Uno32, and then show restoring the Uno32 bootloader. This is the same video as included in the post below, but I duplicated it here for convenience.

KeithV Digilent

jumpin_jack

Fri, 14 Oct 2011 00:49:09 +0000

Hi, Thanks for these instructions. They look promising. I'm not clear on whether another tool like PICkit 3 is required for debugging. Also, this procedure will erase the bootloader, right?

KeithV

Fri, 14 Oct 2011 03:24:32 +0000

For the Max32 and Uno32 you will need the PICkit3. Yes, this will erase the bootloader, but there are instruction in the document on how and where to reinstall the produciton bootloader.

caroper

Sun, 16 Oct 2011 16:12:09 +0000

Excellent Kieth, far better than the earlier version.

Unfortunately I have loaned someone my ICD3, but as soon as I get it back I look forward testing out this method.

Cheers Chris

JimG

Thu, 20 Oct 2011 09:07:58 +0000

I've just got all the bits together to try out this method but I have hit one problem right away - I can't get the hex file address from the verbose output. By the time the verbose output stops, all I have in the readout is a long list of red entries which looks like the end of the uploaded data to the board, finishing with "avrdude done. Thank you.". There is no sign of any addresses for the files generated. I'm using the 22nd August version.

I've also tried using search in Win7 for recently written files but haven't found anything that looks like a likely candidate so far.

Jim.

JimG

Thu, 20 Oct 2011 09:21:56 +0000

I've just got all the bits together to try out this method but I have hit one problem right away - I can't get the hex file address from the verbose output. By the time the verbose output stops, all I have in the readout is a long list of red entries which looks like the end of the uploaded data to the board, finishing with "avrdude done. Thank you.". There is no sign of any addresses for the files generated. I'm using the 22nd August version. I've also tried using search in Win7 for recently written files but haven't found anything that looks like a likely candidate so far. Jim.

Take it all back. I just did a bit more digging around and found that my chip select had somehow reverted to the basic Uno and was not set to the Uno -Debug. I've now got the hex address of the file. :)

Jim.

KeithV

Thu, 20 Oct 2011 14:52:38 +0000

Jim,

For debugging you do not want to use the .hex, you want to use the .elf, the .hex does not have all of the debug information in it. The .elf contains both the .hex and debug information. This is outlined in the document.

Good luck, let me know how it goes.

JimG

Thu, 20 Oct 2011 15:42:30 +0000

For debugging you do not want to use the .hex, you want to use the .elf, the .hex does not have all of the debug information in it. The .elf contains both the .hex and debug information. This is outlined in the document. Good luck, let me know how it goes.

Mixed results. :)

I'm using the latest version of MPLAB downloaded off the Microchip web site - 8.76. I'm also using the Blink program as the test - I can change the delay times and re-compile to give an easily identifiable new program from the LEDs operation on the board - just to make sure I am actually uploading a new program.

MPLAB runs up and recognises the PicKit3. I also can import the .elf file and debug/program it into the Uno. I also load the .pde file but I cannot get it to set breakpoints. When I double click on a line to set a breakpoint, I only get a hollow red ring in the left hand margin and when I debug/run, I get an error message saying

"One or more breakpoints could not be resolved...Select breakpoints from the debugger menu for details"

When I select the breakpoint menu, no breakpoints are shown.

If I get rid of the message, the program runs. If I halt it, a debug window appears showing the program stopped at a line (usually in one of the delay loops in Blink). If I try to Step Through or over, the whole lot appears to hang and I can only get control back by doing a Debug/reset.

The only way I can get the filled red ring with the white B to appear on the left hand margin is to set my selected tool to "None".

Also, the bootloader I reload onto the Chipkit only seems to let me compile sketches, but doesn't run them. This bootloader is downloaded from the Digilent site and is dated 19th August.

So good in parts - and I'm stuck with a Chipkit which will only run under PicKit3 control with no debugging. :)

All good fun.

Jim.

PS - What a miserable forum - only allows up to two smilies.

jasonk

Fri, 21 Oct 2011 05:31:14 +0000

When I double click on a line to set a breakpoint, I only get a hollow red ring in the left hand margin

I believe that mpide copies the source files to a temporary directory when compiling them. That means that the image is associated with the files in the temporary location rather than in the original location. You might be able to set breakpoints in those temporary files.

Also, the bootloader I reload onto the Chipkit only seems to let me compile sketches, but doesn't run them.

Make sure that you are programming the bootloader from the programmer menu rather than the debugger menu. When you program from the debugger menu, the debug tool programs the device in background-debug mode and and then the device expects a debugger to control it.

P.S. You can now use up to 3 smilies in a post :D :lol: ;)

JimG

Fri, 21 Oct 2011 19:57:27 +0000

I believe that mpide copies the source files to a temporary directory when compiling them. That means that the image is associated with the files in the temporary location rather than in the original location. You might be able to set breakpoints in those temporary files.

I'll go looking for the files in the temp location - thanks for the pointer

Make sure that you are programming the bootloader from the programmer menu rather than the debugger menu. When you program from the debugger menu, the debug tool programs the device in background-debug mode and and then the device expects a debugger to control it.

I'm pretty sure I used the programmer menu, but I haven't been able to check things out again aince I find that I cant upload to the Chipkit since MPIDE can't get access to the virtual Com port. If MP LAB and the PicKit3 also use a virtual com port on the USB link, then I think that I've got a clash between the MPIDE and MPLAB. I've been over the PC (it's a Win7 Netbook) for any other com port usage and can't find anything. The MPIDE/Chipkit worked well until I installed MPLAB and used Pickit3. Further investigation will have to wait till next week since I'm going to be doing other things over the weekend.

P.S. You can now use up to 3 smilies in a post

Your generosity astounds me, but I've got to remove your quoted ones to get my three in. Shouldn't ones in quotes be ignored? . :) :) :)

Jim

KeithV

Mon, 24 Oct 2011 15:10:55 +0000

Jim,

Would you do me a favor? Download the document attached to the first message in this form topic. Then follow the detailed instructions under "the specifics" line by line. I think both of your problems will be resolved. should be able to attach to the correct file (which is a .cpp file in the temp directory) and successfully reload your bootloader (under "when you are done debugging").

:D

JimG

Tue, 25 Oct 2011 11:17:19 +0000

Jim, Would you do me a favor? Download the document attached to the first message in this form topic. Then follow the detailed instructions under "the specifics" line by line. I think both of your problems will be resolved. should be able to attach to the correct file (which is a .cpp file in the temp directory) and successfully reload your bootloader (under "when you are done debugging").

Keith,

I had some more attempts to get things working last night but with the same results The PicKit3 is definitely hooking up to the ChipKit since it does upload the program and it can be run under Debug/Run - I'm still using "Blink" as the test and setting different delays so that a new version can be indentified from the LEDs when running. Basically, from MPLAB I can upload and Debug Run/Halt the program, but cannot set a break point (empty red circle in margin) and can't step through the program. I think I was reading through the document carefully and made sure I imported the ELF file and loaded the .cpp file from the temp directory. I'l have another go later today to see if I can get any further.

I've still got the problem of not being able to hook up to the Chipkit from AVR after I've reloaded the bootloader. I get the message about the serial poirt aready being in use. The only other things using USB are my mouse and PicKit3. I've tried disconnecting the mouse and Pickit and uninstalling and re-installing Virtual Com Port drivers, but with no improvement. When the ChipKit is powered down and powered up, the program which was uploaded with PicKit3 starts and runs.

I might try the setup on a different PC. I've been using a Netbook with Win7 Starter so far but I have a spare PC with Vista in the attic so I might get it down to see if matters improve. I don't want to try them on my main PCs in case it adversely affects the USB ports on them in any way.

Also, I have to confess that I've started looking at just working with MPLAB and the PicKit3 and forgetting about AVR. There's no C++ so far with MPLAB, but I did note a message on another forum that C++ might be on the way so I could potter around trying things out with C32 until that happens

Jim.

jasonk

Tue, 25 Oct 2011 15:26:26 +0000

By "AVR" do you mean mpide?

Also, there are some hints for running getting a debug-able image here: http://www.chipkit.org/forum/viewtopic.php?p=2546#p2546 The thread is talking about pic32-objdump, but most of the tips also apply to running the ELF file in MPLAB IDE v8's debugger.

As far as reprograming the bootloader, you're programming from the programmer menu and not the debugger menu, right? (I think that I already mentioned that in this thread, but that's the only idea that comes to mind at the moment.)

KeithV

Tue, 25 Oct 2011 19:01:29 +0000

Jim,

I am at a loss as to what is going on. I have attached a .WMV (MediaPlayer) video of debugging the Blink example on an Uno32. Then I reprogram the Uno32 with the production bootloader.

Sorry, there are some delays in the video here and there; I did not spend much time in the production of this.

Hope this helps.

KeithV Digilent Inc.

JimG

Tue, 25 Oct 2011 21:30:06 +0000

Jim, I am at a loss as to what is going on. I have attached a .WMV (MediaPlayer) video of debugging the Blink example on an Uno32.

Keith, Jason,

It works. :)

I'm not exactly sure what was going on but I was being really thrown by the apparent clash of the Com port usage and also the fact that my Netbook was running very slowly. So I've been chasing apparent problems with the machine, checking for viruses and malware and restoring to before recent large Windows and Java updates.

But just a short while ago I uploaded the bootloader to the Uno and it started working properly again. I also did some more work with the MPLAB IDE and found that I can't set the break point on the first Setup() line of the Blink program, but I can set the breakpoint in any line inside Loop() and the program will stop on them and I can step from them (although picking a program with two bloody great delay loops doesn't make for a great demonstration of debugging. :)

Rather than copying the temp file details from the verbose output of the MPIDE, I use that information to give me the location, then I set up to go to that location and look for a temp folder with the appropriate time signature to find the elf and hex files.

I also noted one small problem - reverting to normal MPIDE working, the upload operation hangs if you are in the UNO MPLAB Debug setting and try and upload in non-verbose.

Jim

KeithV

Wed, 26 Oct 2011 00:24:41 +0000

That is Great!

The reason I specifially suggest cutting the elf file from the verbose listing is that MPLAB is very picky about the source files, and MPIDE copies a lot of source to the temp directory and those are the ones MPLAB expects to use, so poking about trying to find all of the correct files is VERY problematic. It is just easier to copy the path from the verbose listing.

If you upload a Debug MPLAB board, you should get an error like the following:

avrdude: ERROR: address 0x1fc004a0 out of range at line 867 of C:\Users\KeithV\AppData\Local\Temp\build1616012323864590645.tmp\BlinkMAX32.cpp.hex avrdude: write to file 'C:\Users\KeithV\AppData\Local\Temp\build1616012323864590645.tmp\BlinkMAX32.cpp.hex' failed

I just did this non-verbose and got the error. You may hang if you have not restored the bootloader as the bootloader returns this error (and will only do so if bootloader is there). What is happening is that the Debug image has config bits in it, and the bootloader will not let you overwrite them. I suspect when you tried an upload from MPIDE, you had not restored the bootloder yet.

The breakpoint should go on the function name, not really the first line. With optimizations OFF breakpoints are pretty good on the lines, however optimizing makes breakpoints a hit or miss thing as actual code gen is non-intuitive. If on the blink example you could not set the breakpoint on the setup function name itself, I wonder if you really had the correct source file loaded with respect to the image. Again, I would copy that elf file from the verbose listing and since the pde file is copied by MPIDE as a cpp file to the temp dir, you need to use that same path for the cpp sketch file name.

There is still an issue with local variable in C files; this is a debug symbol generation problem. Most times local variable are going to appear out of scope when using the MPIDE gcc compiler. Jason knows about it. The Watch windows seems to work well for global variables. And of course your real power comes from the memory, register, and dissassembly windows.

Glad you got it to work.

KeithV Digilent.

KeithV

Sat, 29 Oct 2011 01:22:59 +0000

I corrected a problem with the debug config bits, I had the peripheral clock set to div 8 instead of div 1. This caused the timers to run 8 times slower when debugging. I updated/edited the original posting (go to the first posting in this thread) with all of the new files.

Thanks KeithV Digilent

Bypeduredads

Tue, 06 Dec 2011 18:13:17 +0000

New users? Ive been using the program for years and didnt know that. Well, worse. I remember it now that you reminded me.

Where is this help thing you were talking about.

Good Tip.

KeithV

Wed, 07 Dec 2011 17:28:06 +0000

Not sure what you are referring to in your comments. But the help files can be found on the very first posting on this form topic. See the attachments.

EmbeddedMan

Thu, 08 Dec 2011 03:35:33 +0000

Keith, the comment you are replying to is robo-spam. Generic text, meant to look close enough to a real comment that it can be sprayed in any forum about anything and not look too out of place. At least it seems that way to me.

*Brian

Jacob Christ

Thu, 08 Dec 2011 08:01:10 +0000

Keith, the comment you are replying to is robo-spam. Generic text, meant to look close enough to a real comment that it can be sprayed in any forum about anything and not look too out of place. At least it seems that way to me.

I agree, I wonder what the motivation of the robo text is, just be annoying or to try to establish an account prior to posting ads?

Jacob

EmbeddedMan

Thu, 08 Dec 2011 15:42:05 +0000

I'm pretty sure the latter. I've seen it on other boards. The robot doesn't know how many 'clean' posts it needs on a given board before it can post links, so my guess is that it keeps adding these clean posts and trying with links until it can succeed.

*Brian

KeithV

Thu, 08 Dec 2011 16:04:50 +0000

Thanks guys for clueing me into the realities of today’s world; I just don’t understand these kinds of frivolous acts. I think someone has too much time on their hands.

KM6VV

Thu, 08 Dec 2011 18:22:21 +0000

That explains it! I thought it might have been kids.

Thanks.

Alan KM6VV

KeithV

Thu, 09 Feb 2012 22:49:13 +0000

MPIDE 20111221 changed debugging in a few ways, some good, some bad. I have updated the MPIDE20111221_MPLAB_Debug_.zip file to enable debugging on MPIDE 20111221, ONLY. Here is what changed:

  1. Board variants were added which is an extra entry in board.txt, so if you use the debug boards.txt that was provided with MPIDE 20110907 they will give you a compile error.

  2. I added the MX3cK to the debug list of boards.

  3. MPIDE 20111221 has a code generation bug in wiring.c with the inline definition of write_comp() asm macro. By chance only, the code generated with optimizations ON works; but with optimizations OFF, the error freezes the delay() function. This .zip file corrects the write_comp() asm macro.

  4. When fixing write_comp() in wiring.c it was noticed that the core timer code still had some issues, it was rewritten to fix the problem; but this also required an update to PWMServo which was rewritten to work with the fixed core timer handler.

MPIDE20111221_MPLAB_Debug_.zip will put a corrected boards.txt and give you debug linker scripts as well as update write_comp, core timer handler, and the PWMServo library. Just place this in the same directory where MPIDE.exe is found by default and extract in place. You will get some messages asking if you want to replace some files, say yes as these are the corrected files. Once you get this installed, you will be debugging as before with MPIDE20110907.

When the next official build of MPIDE is released, I will have to back off and only provide the boards.txt and linker scripts; so this .zip file if for MPIDE 20111221 ONLY.

peplin

Wed, 29 Feb 2012 16:26:40 +0000

Hi Keith - thanks for your work on the debugging procedure. I've almost got it working with a PICkit3 and Max32 in MPLAB X.

With your updated version of wiring.c (and other files) I can program and run the debuggable version of the Blink example - the LED blinks and I can pause execution from MPLAB X. The problem is that it always lands me on the same line of source code - in the delay() function. If I try single stepping from there, it just seems to hang until I hit continue.

If I open up the Blink.cpp file from the temporary build directory and mark breakpoints, they all show up as "unrecognized" and never halt the program. Strangely enough, when I hit the button to pause execution it opens up the wiring.c file from the MPIDE's installation directory, not the one copied to the temporary build directory.

I think the root problem is that the source files aren't being properly linked to the compiled .elf as far as MPLAB is concerned. I tried this in MPLAB 8 and had similar results - when I pause execution it pops open wiring.c, but single stepping from there just makes execution halt completely.

Chris

peplin

Wed, 29 Feb 2012 17:04:59 +0000

I've just had some mild success: after programming using the debugger, I opened View -> Disassembly Listing. I was able to put breakpoints in here and have the chipKIT actually stop.

This is workable but I'd like to be able to do this without the assembly mixed in - it's a lot of noise that doesn't matter for what I'm trying to debug.

peplin

Wed, 29 Feb 2012 18:58:03 +0000

Success in MPLAB 8! I did not realize how extremely picky MPLAB 8 is about the source code path.

In the disassembly listing I noticed that the path to the sketch's .cpp file was:

C:\DOCUME~1\cpeplin\LOCALS~1\Temp\build2417076219088889289.tmp\Blink.cpp

I recognized the "~1" junk as Windows shorthand, and an initial attempt at copy+pasting the entire path into the open dialog didn't work. I just navigated to that temp directory and opened the .cpp file. The path of this file as MPLAB saw it was:

C:\Documents and Settings\cpeplin\Local Settings\Temp\build2417076219088889289.tmp\Blink.cpp

No luck - problems are described in my earlier post.

Trying to follow the steps exactly I finally got it to copy and past the path with the Windows shorthand and BINGO, it works!

So false alarm, but if anyone else is having trouble, take note that the path you use to open the source must EXACTLY match the one referenced in the disassembly view.

KeithV

Tue, 06 Mar 2012 04:23:13 +0000

That is correct, the path must be exact; thus the cut and paste from the output window from MPIDE.

My take from all of this is that you are working fine; that is great. Sorry I was offline for a few days...

cgclepper

Thu, 18 Oct 2012 22:42:52 +0000

Hi

What is the status of this with MPLAB X on the Mac? I get this error: The program file could not be loaded: com.microchip.mplab.mdbcore.program.exceptions.ProgramFileProcessingException

I'm currently stuck with two options: I can generate the code I want in MPIDE, but not debug it. Or, debug ultra slow code without the nice Libraires in MPLAB X. The PIC32 is far too complex of a device to be without a debugger and I don't really like having to pay ransom for a compiler flag.

Thanks!