Dangerous Prototypes

Of course we managed to blow away the boot loader on the web platform.

Not having a real PIC programmer (only AVR and JTAG stuff) I started hacking around with
PiratePICprog.  I added a chip description in pic.c:

    {
		.name = "33FJ128GP204",
		.ID = 0x627,
		.flash = 512*256,
		.eeprom = 0,
		.family = FAMILY_24FJxxGAxxx,
	}

and hooked up the bus pirate according to the wiki page for PiratePICprog.  You then run into
the same problem when using pirate-loader on the web platform.  The hex files generated by
mplabx, and the bootloader dp-wp-bootloader.v0a.hex have addresses outside the range
of the flash memory.  For the boot loader, it has:

:0200000401F009
:10000000FFFF0000FFFF0000FFFF0000F9FF0000FE
:10001000FFFF00007FFF0000F8FF0000C3000000AA
:10002000FF000000FF000000FF000000FF000000D4

which writes a bunch of config stuff at starting address 0x01f0 0000.  A brief poke at the data sheet
shows that this is a lot like the fuse bits on the AVR.  Deleting this from the HEX file allows
piratePICprog to flash the bootloader and lets us continue development.

In the long run, manually hacking HEX files is not a good thing.  Now, I don't really know enough
about the PIC to understand what the right thing to do here is.  The code that reads HEX files
in piratePICprog does NOT do the right thing here since it assumes that the address space of the
HEX file is contiguous and this out-of-band data is far away from the valid flash addresses.
HEX files generated by mplabx are full of these references to 0x01f0 0000, and they are
scattered within the file (unlike the boot loader where it's at the end).

So my question is:  what's the right thing to fix?

This is the primary issue that stalled piratePICprog development. The flash configuration bits are at a high address, and the parser is not smart enough to know there are different blocks of code. I thought this was limited to old 8bit 5volt PICs though. I thought the new 16bit PICs stored the config bits at the last flash address and they were copied into registers at startup. I have not specifically looked at the ds33 though, only the 18FxxJ, and 24Fj64.

If you want to fix it up, I would suggest tackling the PC app.

However - it sounds like your config words are intact. Maybe you could just program the bootlaoder (without config words) and keep using it.