UPDATE: FIXED!

Apparently the MX170 is not yet in openOCD's device-listing:

I don't fully understand it, and it was a VERY round-about way of coming to this rather simple conclusion. This does require recompilation of openOCD.

1. Edit the file openocd-0.9.0/src/flash/nor/pic32mx.c
2. Add your CPUTAPID (see note) to pic32mx_devs[] ('round line 120).
   1. NOTE, add the CPUTAPID & 0x0fffffff... or *drop* the first nibble... e.g. the MX170F256B has a CPUTAPID of 0x26610053, the line added looks like:
      

      1. {0x06610053, "170F256B"},

   2. NOTE2: Based on my understanding of the code, it looks like you can add your device listing anywhere in the list (it doesn't have to be sorted).
3. Recompile openOCD and place the executable appropriately
   1. (either 'make install', or if already done with an older version, just copy src/openocd over /usr/local/bin/openocd)
      

Was:

"It shoulda been simple" the phrase of this era... re: flashing the MX170...

The latest: For the motion-control code, I planned to switch to the MX170 rather than the MX230 used in this "project" because the 170 has several 5V-tolerant pins which would lend themselves well to my H-Bridge chip. Really, technically, the only differences should be a slight pinout change, and more flash-memory. In fact, they share the same datasheet; their registers are identical everywhere I've looked, the configuration-bytes are identical (as far as the PLL, etc...). The code compiles with no changes other than switching the xc32-gcc MCU argument, appropriately. And, in fact, I've even run "diff" on the disassembly-listings as well as the intel-hex files(!) and the only differences are a few address differences ((the 230 was 64KB, the 170 is 256KB, apparently some exception(?) routines are placed near the end of the FLASH).

So... what on earth could be wrong...?

The best I've come up with, after much effort, is that somehow the program-FLASH is only being written in the first row (128bytes) and then it appears to be empty, despite the flashing-procedure not giving any errors. I've tried two chips, now I'm fighting with the Really Slow Flashing Method (half an hour for 256KB?!) to see if it functions differently... I think this is an openOCD thing. It's just *really weird*. These chips should be nearly identical, in fact I'm almost certain I should be able to run the hex-file compiled for one on the other.

Not sure if/how I'd've ever figured this out without single-stepping... it's not a problem with *my* code, probably not a code problem at all (as far as the code running on the chip, judging by the diffs)... Just Weird.

Maybe it'd been worth it to use the Microchip tools (programmer, etc.) after all...

HAH! "Slow-Flash" ended-up failing on the *other* flash-bank...

So, now we have: If I "fast-flash" (using the hacked openOCD), it writes the BOOT flash properly, but not the program-flash... then I can "slow-flash" (using the unhacked openOCD) and it will write the program-flash but not the boot flash! LOL. IT RUNS! LOL!