For this procedure, I will assume you're using:

• PIC32MX230F064B
• FTDI FT2232H breakout board

These notes are tested on a Linux system, but these instructions should be helpful for OSX or Windows, as well.

These instructions are for a 'bare-metal' configuration (as opposed to running an application atop an operating-system like Linux or BSD).

These instructions are for command-line based utilities, NOT using an IDE.

(Oh, and I'm certainly no expert, there are probably better instructions out there, somewhere...)

Wire up your PIC32's MINIMUM requirements as-shown:

(a summary of the related Project Log)

(NOTE: If this page wraps-weirdly, try *shrinking* your window-width, counterintuitively)

( '#' = MUST BE CONNECTED )
( '*' = 5V-tolerant )

3V3
 ^
 |
 \
 / 10K           PIC32
 \                  MX2xxFxxxB       3V3
 /                ___________         ^
 |  1k           |    |_|    |        | .1uF
 +-/\/\-- /MCLR -|1*#     #28|- AVDD -+--||--.
 |        RA0   -|2       #27|- AVSS / AGND -+-> GND
===.1uF   RA1   -|3        26|- RB15
 |  PGED1/RB0   -|4        25|- RB14
 |  PGEC1/RB1   -|5        24|- RB13
 |        RB2   -|6     (#)23|- VUSB3V3 ---> 3V3
 v        RB3   -|7        22|- RB11
GND<---- GND/VSS-|8#       21|- RB10     10uF TANT/CER
 ^        RA2   -|9       #20|- VCAP ----||--.
 |        RA3   -|10      #19|- VSS / GND ---+-> GND
===.1uF   RB4   -|11      *18|- RB9/TDO
 |        RA4   -|12      *17|- RB8/TCK
 +------ V+/VDD -|13#     *16|- RB7/TDI
 |       TMS/RB5-|14*     *15|- VBUS (N/C OK)
 v               |___________|
3V3

(For the 10uF capacitor, I used two parallel 4.7uF tantalums)

The PIC32MX1xxFxxxB series minimum-wiring requirements should be *nearly* identical, though there are some minor, but important, pinout differences.

(NOTE: RB0/RB1 are not available as GPIO by default, due to PGED1/PGEC1 being the In-Circuit Programmer pins!)

Wire the PIC32's JTAG pins to the FT2232H breakout-board/JTAGger:

Pin Mapping:

PIC32MX2xxFxxxB     JTAG signal    FT2232H (JTAGger)
14                  TMS            AD3
16                  TDI            AD1
17                  TCK            AD0
18                  TDO            AD2
(GND)               (GND)          (GND)
(3V3)               (3V3)          (3V3)

NOTE: I'm assuming you're taking 3V3 FROM the FT2232H
      breakout-board, to *drive* the PIC32!
      (Add a large-ish (22+uF) capacitor where
       3V3 and GND enter your PIC32's breadboard)
NOTE 2: I am NOT connecting nTRST nor nSRST at this
        point.

Get the software:

openOCD:

These instructions were developed using a hacked version of openOCD 0.90. Early tests worked with 0.80, but with many caveats that I personally found unbearable (e.g. 10 minutes to flash a 64kB device!). I highly recommend you build the hacked version of 0.90.

Microchip's MPLAB xc32-gcc:

http://www.microchip.com/pagehandler/en-us/devtools/mplabxc/home.html

Click the "Downloads" Tab, and select the "Compilers" drop-down.

Select the XC32 version for your operating system: "MPLAB® XC32 Compiler v1.40 - Legacy Peripheral support libraries not included"

Note: This is NOT the MPLABX IDE, this is the command-line tool-chain, so you can run e.g. 'xc32-gcc' from the command-line, or use your favorite IDE.

(Yes, I had every intention of using an entirely open-source toolchain, and unfortunately that goal has been above my means. BUT: The XC32 compiler is free, it is gcc, and is in fact open-source. What's NOT open-source is the header and linker-files that come with the package, which are basically necessary).

NOTE: xc32-gcc seems to be working a bit funky with my system... you might have to add extra "escaping" of quotes used on the command-line. E.G. gcc -DTHING="Thing String" may work with your normal GCC package, but xc32-gcc might require xc32-gcc -DTHING=\"Thing String\" (or even -DTHING=\\\"Thing String\\\"!)

OpenOCD configuration files:

On my system, the openOCD configuration files are located in subdirectories under /usr/local/share/openocd/scripts/

The FT2232H board, as-wired, matches the "Flyswatter" JTAGger's pinout/configuration. (As-wired, we're neglecting/disregarding the "Flyswatter" buffer-circuitry, so use some common-sense... don't leave it powered-up while changing wiring!)

The file interface/ftdi/flyswatter.cfg was copied and modified for this "hacked" pseudo-flyswatter:

interface/ftdi/myFlyswatter.cfg:

interface ftdi
#comment out the following line!
#ftdi_device_desc "Flyswatter"
ftdi_vid_pid 0x0403 0x6010

ftdi_layout_init 0x0818 0x0cfb
ftdi_layout_signal nTRST -data 0x0010
ftdi_layout_signal nSRST -oe 0x0020
ftdi_layout_signal LED -data 0x0c00

The PIC32MX230F064 does not have a specific configuration-file, so we'll have to create our own.

board/pic32_my2xx.cfg:

#This is a copy-paste from pic-p32mx.cfg, and modified for my chip...
# ORIGINAL NOTE:
# The Olimex PIC-P32MX has a PIC32MX

set CPUTAPID 0x14d01053
source [find target/pic32mx.cfg]

From this point on, openOCD can be called via:

openocd -f interface/ftdi/myFlyswatter.cfg -c "adapter_khz 4000" -f board/pic32_my2xx.cfg

NOTE: I have now opted to move my custom configuration files to a separate directory, so they can be copied-over with a project to a different system... This is handled, simply, by changing the -f <file> options, e.g. openocd -f ~/projectCommon/openOCDscripts/myFlyswatter.cfg .... However, of course, the different system still needs the custom-compiled openOCD 0.90, as described earlier.

Automatic flash-programming script:

See the original script at: https://github.com/kinsamanka/PICnc-V2/wiki/OpenOCD-PIC32-Programmer

pic32_flash.sh:

#!/bin/bash

# This is taken almost directly from kinsamanka at github.com:
#https://github.com/kinsamanka/PICnc-V2/wiki/OpenOCD-PIC32-Programmer

# His file was called pic32openocd

#TODO: I need to make sure to check his opensource licensing requests!


#TODO: Also need to look into making this device (not board) selectable...
#      e.g. via MCU...?
#      (currently I'm using a custom board.cfg)

if [ -z $1 ]
then
  echo "firmware file is missing!"
  echo "Usage: $0 <hexfile>"
  exit
fi


# Run openocd, but keep the script running... ('&')
openocd -f interface/ftdi/myFlyswatter.cfg -c "adapter_khz 4000" -f board/pic32_my2xx.cfg &

sleep 1

#Clever(?) piping... and nc instead of telnet...
(
echo 'reset init'
sleep 1
echo pic32mx unlock 0
sleep 1
echo reset init
echo program $1 reset exit
) | nc localhost 4444 > /dev/null

# It appears that nc keeps running until the exit command (in program) is
# executed, which causes the 'telnet' connection to drop *and* exits
# openOCD...
# So... I don't know, off-hand, how to use the same openocd session to
# *resume*...

# This bit causes the flashed program to execute
# (Otherwise, it would remain in 'halt' until power-cycled 
#  or /MCLR manually asserted (via pushbutton?))
openocd -f interface/ftdi/myFlyswatter.cfg -c "adapter_khz 4000" -f board/pic32_my2xx.cfg &

sleep 1

(
 echo reset halt
 sleep 1
 echo resume
 sleep 1
 echo shutdown
) | nc localhost 4444 > /dev/null

(Don't forget to mark this file executable!)

So now you can run, e.g.:

pic32_flash.sh flashFile.hex

NOTE: This process is *very slow*, it takes nearly 10 minutes to flash 64KB...

There appears to be a configuration option I've not yet figured out, as it gives the following messages:

Error: mini program did not return to start
Error: fast_data (0xa00008d8) is within write area (0xa0000958-0xa0001158).
Error: Change work-area-phys or load_image address!
Warn : Falling back to non-bulk write

UPDATE: I am now able to flash in a matter of seconds... It was an ordeal I don't remember, and the project-log on it is equally-convoluted. But if you wish to attempt it see here: https://hackaday.io/project/6450/log/20840-wherein-we-discover-with-some-amount-of-certainty