Skip to main content
Topic: Use your PICkit2 or PICkit3 as a debugger for PIC32 (Read 15694 times) previous topic - next topic

Use your PICkit2 or PICkit3 as a debugger for PIC32

Hello,
 
A new opensource project started: http://code.google.com/p/ejtagproxy/
It's a command-line utility, which connects GDB to ICSP port of pic32 via pickit2 or pickit3 scripting edition.  A standard GDB remote serial protocol is implemented. It also can be used with Eclipse, DDD, Insight or other compatible debuggers.  All families of pic32 are supported, including mx1/mx2.  The utility works on Linux, Windows and Mac OS X.  Sources are available under BSD license.
It also supports debugging via JTAG port with Olimex JTAG USB-Tiny adapter.
Any feedback appreciated.
 
Thanks,
Serge

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #1
Great! your pic32prog works very well and saved me having to buy a pickit 3. Maybe this project will give me a debugger also. One question though, where did you get the specification for the pic32 debugger? Hav microchip made this open or did you reverse engineer it?

EJTAG spec is open

Reply #2
Ejtagproxy was designed to be used in companion with pic32prog.  When a debug session is finished, it closes a JTAG connection, making it free for pic32prog to replace the flash memory contents.  Then a new debug session can be started.

PIC32 is based on M4K core, which has a standard MIPS EJTAG debug block.  The specification is freely available (http://www.mips.com/secure-download/ind ... D05.06.pdf).  Microchip had extended it with a few non-standard JTAG commands.  OpenOCD has a support for PIC32, and I used some code snippets from it.  The most tricky part was to figure out a pickit2 protocol.  Fortunately, pk2cmd application and pickit2 firmware are opensource (http://ww1.microchip.com/downloads/en/D ... 21_RC1.zip, http://ww1.microchip.com/downloads/en/D ... -32-00.zip).  Careful study of the sources and trace files made ​​it possible to understand all the details and implement it efficiently.
--Serge

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #3
Good work,

Any reason why you did not use OpenOCD as a base ?

Cheers
Spen

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #4
Thanks Spen.
First reason is that OpenOCD is not suitable for PICkit2/3 kind of adapters.  Internally OpenOCD creates a bit stream of TDO/TMS data, delivered to a target device via adapter.  But so called scripting instructions of PICkit2/3 are more high-level and have a different semantics.  They cannot be easily mapped to a JTAG data stream.  I would require an additional complex layer of translation software, hard to create and error-prone.

Second reason is simplicity.  OpenOCD code size is 20 times larger than ejtagproxy.  It requires an adapter-dependent and target cpu-dependent configuration file.  With four supported adapters and 69 models of pic32, it goes to 276 different variants.  Ejtagproxy needs no configuration: it "just works".

Third is a speed.  OpenOCD is too generic, as it tries to be a full-featured debugger by inself.  Ejtagproxy implements only features, needed for GDB, and does it efficiently.  For example, single stepping with ejtagproxy is about three times faster than with OpenOCD, on the same hardware.
--Serge

Re: EJTAG spec is open

Reply #5
[quote author="SergeV"]
PIC32 is based on M4K core, which has a standard MIPS EJTAG debug block.  The specification is freely available (http://www.mips.com/secure-download/ind ... D05.06.pdf). 
--Serge[/quote]

Of course! Thank Serge. I was getting confused with other PIC families where the microchip debug specification has not been documented and locked up in a "debug executive." OF course the PIC32MX uses JTAG so that is not so much an issue.

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #6
Great Job.
Does it also support Olimex PIC-KIT3?

-- rd

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #7
[quote author="SergeV"]Thanks Spen.
First reason is that OpenOCD is not suitable for PICkit2/3 kind of adapters.  Internally OpenOCD creates a bit stream of TDO/TMS data, delivered to a target device via adapter.  But so called scripting instructions of PICkit2/3 are more high-level and have a different semantics.  They cannot be easily mapped to a JTAG data stream.  I would require an additional complex layer of translation software, hard to create and error-prone.
--Serge[/quote]

True however we have done something similar with the stlink, this is a also high level adapter.

[quote author="SergeV"]
Second reason is simplicity.  OpenOCD code size is 20 times larger than ejtagproxy.  It requires an adapter-dependent and target cpu-dependent configuration file.  With four supported adapters and 69 models of pic32, it goes to 276 different variants.  Ejtagproxy needs no configuration: it "just works".

Third is a speed.  OpenOCD is too generic, as it tries to be a full-featured debugger by inself.  Ejtagproxy implements only features, needed for GDB, and does it efficiently.  For example, single stepping with ejtagproxy is about three times faster than with OpenOCD, on the same hardware.
--Serge[/quote]

I will have a scan through your code as it would be good to get any speed improvements you have found merged back into OpenOCD.

Spen

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #8
[quote author="rockeedean"]Great Job.
Does it also support Olimex PIC-KIT3?[/quote]
Looks like Olimex PIC-KIT3 is an exact clone of an original PICkit3.  Try PICkit 3 Scripting Tool: if it will detect and upgrade a firmware of PIC-KIT3, then it should work perfectly.

[quote author="ntfreak"]I will have a scan through your code as it would be good to get any speed improvements you have found merged back into OpenOCD.[/quote]
To optimize for speed, I usually use a slower adapter (FT2232, not FT2232H).  Easier to see all the slowdowns.
--Serge

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #9
I have slightly modified Serge's code to add support for Bus Blaster 2.5 in his awesome ejtagproxy tool. Seems to be working so far. It still needs further testing, however. I'm posting this just in case anyone is interested.

Best,

Mikelelere

Bus Blaster support integrated

Reply #10
[quote author="mikelelere"]I have slightly modified Serge's code to add support for Bus Blaster 2.5 in his awesome ejtagproxy tool. Seems to be working so far. It still needs further testing, however. I'm posting this just in case anyone is interested.[/quote]
Thanks, Mikelelere!
I've merged your changes into the main trunk: try svn revision r23.  Pic32prog utility also updated.  Unfortunately, I cannot test it myself: still waiting for my Bus Blaster ordered from Seeedstudio.
--Serge

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #11
Hi Serge,

Great job merging the changes without breaking the support for the Olimex dongle as I did :-). I just downloaded, compiled and tested both utilities and seem to be working fine. Thanks  for these two great utilities!

Edit: I've done further testing on the pic32prog application, and the current revision did not work for me when trying to program a PIC32MX220F032B with my Bus Blaster. Concretely, it failed in the serial_execution function when trying to verify that the device was not in reset state. It  seems that after deasserting the /SYSRST signal the MCHP_STATUS_FCBUSY flag was set in the status register while it shouldn't! I just added a code snippet that polls the status register until this flag is deasserted. Once this was done, the status register matched the expected value and the program could continue execution.

After fixing this issue, the flash process failed again due to some weird error verifying the version of the PE. After close inspection, I believe that the culprit is the adopted buffered approach. The mpsse_flush_output function is not called as often as required, and thus, the code tries to retrieve the response data prior to sending the request/command. I solved this issue by adding a mpsse_flush_output call at the end of the mpsse_send function. I know that this is an ugly patch, but it did work for me. Maybe flushing the transmit buffer prior to reading any data from the mpsse  would be a better solution...

After performing these fixes I was able to successfully flash the device. I have also tested it against a PIC32MX795F512L and it does work too! However, I do not know if these changes broke the Olimex ARM-OCD-USB support (they shouldn't). I cannot test it since I do not own one. I do also think that it is advisable to apply the same patch to the ejtagproxy code to prevent similar issues.

Please, find attached the patched adapter-mpsse.c file (the one for pic32prog) and the patched adapter-mpsse-ejtagproxy.c file (for ejtagproxy).

Best,

M.

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #12
Thanks everyone, I'm glad the Bus Blaster is working out for you.

Quote
Unfortunately, I cannot test it myself: still waiting for my Bus Blaster ordered from Seeedstudio.

You should give me a shout, we always send stuff to open source project developer for free. When v4 is available I will send you one.

I added a link to the project to the Bus Blaster manual.
Got a question? Please ask in the forum for the fastest answers.

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #13
[quote author="ian"]You should give me a shout, we always send stuff to open source project developer for free. When v4 is available I will send you one.[/quote]
Wow, excellent!  Thanks, Ian.  I'll be glad to add a support for v4.

[quote author="mikelelere"]Edit: I've done further testing on the pic32prog application, and the current revision did not work for me when trying to program a PIC32MX220F032B with my Bus Blaster. Concretely, it failed in the serial_execution function when trying to verify that the device was not in reset state. It  seems that after deasserting the /SYSRST signal the MCHP_STATUS_FCBUSY flag was set in the status register while it shouldn't! I just added a code snippet that polls the status register until this flag is deasserted. Once this was done, the status register matched the expected value and the program could continue execution.[/quote]
Thank you for the pathes files - I should investigate this issue.  I guess it's caused by a slow CPU clock.  When a clean chip is programmed, PE starts with default clock settings, i.e. internal 8MHz RC oscillator.  This is too slow.  Probably, before loading PE, pic32prog should enable PLL and accelerate it to 40MHz or something.

--Wishes,
Serge

Re: Use your PICkit2 or PICkit3 as a debugger for PIC32

Reply #14
[quote author="SergeV"]I guess it's caused by a slow CPU clock. When a clean chip is programmed, PE starts with default clock settings, i.e. internal 8MHz RC oscillator. This is too slow. Probably, before loading PE, pic32prog should enable PLL and accelerate it to 40MHz or something.[/quote]

Yes, I agree with you. That makes perfect sense...