Use your PICkit2 or PICkit3 as a debugger for PIC32

Hardware incubation. See also our in development projects wiki.

Use your PICkit2 or PICkit3 as a debugger for PIC32

Postby SergeV » Sat Jul 21, 2012 12:15 am

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
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

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

Postby JTR » Sun Jul 22, 2012 1:46 am

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?
JTR
Sr. Member
Sr. Member
 
Posts: 335
Joined: Mon Jan 31, 2011 5:50 am

EJTAG spec is open

Postby SergeV » Mon Jul 23, 2012 3:34 am

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
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

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

Postby ntfreak » Mon Jul 23, 2012 9:15 am

Good work,

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

Cheers
Spen
ntfreak
Newbie
Newbie
 
Posts: 2
Joined: Mon Jul 23, 2012 9:07 am

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

Postby SergeV » Mon Jul 23, 2012 9:58 pm

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
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

Re: EJTAG spec is open

Postby JTR » Tue Jul 24, 2012 12:55 am

SergeV wrote: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


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.
JTR
Sr. Member
Sr. Member
 
Posts: 335
Joined: Mon Jan 31, 2011 5:50 am

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

Postby rockeedean » Tue Jul 24, 2012 8:45 am

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

-- rd
rockeedean
Newbie
Newbie
 
Posts: 1
Joined: Tue Jul 24, 2012 7:25 am

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

Postby ntfreak » Tue Jul 24, 2012 8:53 am

SergeV wrote: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


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

SergeV wrote: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


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
ntfreak
Newbie
Newbie
 
Posts: 2
Joined: Mon Jul 23, 2012 9:07 am

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

Postby SergeV » Tue Jul 24, 2012 3:41 pm

rockeedean wrote:Great Job.
Does it also support Olimex PIC-KIT3?

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.

ntfreak wrote: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.

To optimize for speed, I usually use a slower adapter (FT2232, not FT2232H). Easier to see all the slowdowns.
--Serge
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

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

Postby mikelelere » Fri Jul 27, 2012 6:48 am

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
Attachments
ejtagproxy-busblaster.tar.bz2
(232.7 KiB) Downloaded 462 times
mikelelere
Newbie
Newbie
 
Posts: 35
Joined: Fri Jul 27, 2012 6:42 am

Bus Blaster support integrated

Postby SergeV » Fri Jul 27, 2012 5:07 pm

mikelelere wrote: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.

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
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

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

Postby mikelelere » Sat Jul 28, 2012 5:01 am

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.
Attachments
adapter-mpsse-ejtagproxy.c
(29.11 KiB) Downloaded 402 times
adapter-mpsse.c
(34.56 KiB) Downloaded 361 times
mikelelere
Newbie
Newbie
 
Posts: 35
Joined: Fri Jul 27, 2012 6:42 am

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

Postby ian » Tue Jul 31, 2012 4:45 am

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

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.
User avatar
ian
Crew
Crew
 
Posts: 10803
Joined: Mon Jul 06, 2009 6:14 am

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

Postby SergeV » Wed Aug 01, 2012 10:48 pm

ian wrote: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.

Wow, excellent! Thanks, Ian. I'll be glad to add a support for v4.

mikelelere wrote: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.

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
SergeV
Newbie
Newbie
 
Posts: 6
Joined: Sat Jul 21, 2012 12:03 am

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

Postby mikelelere » Thu Aug 02, 2012 2:07 am

SergeV wrote: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.


Yes, I agree with you. That makes perfect sense...
mikelelere
Newbie
Newbie
 
Posts: 35
Joined: Fri Jul 27, 2012 6:42 am

Next

Return to Project development, ideas, and suggestions