Brendan

Looks great! Yes, for some reason, XC8 v. 2.32 is putting FLASH, Then USER ID, Then CONFIG, then EEPROM (in ascending order) ... but when I flip that ... FLASH, EEPROM, CONFIG, USERID (as you did) it flashes correctly ... Now to figure out why XC8 is doing that! Thanks!

The Q43 Bootloader I was using was 18F_Family15_TBL_REV6 which was provided by you for the Q43 chip ... however, I'm not using that FW at the moment, as it puts the corrupt data on the second half of the first page write (other thread)... However, the EEPROM writing issue I"m seeing is from the PC app. Uploading EEPROM send: 40, 00, 00, 01; FF, C0, receive: 43, send: 40, 00, 01, 01; FF, BF, receive: 43, send: 40, 00, 02, 01; FF, BE, receive: 43, As you can see, the PC app says it's sending EEPROM...

I haven't changed the exe at all ... I've only changed the FW on the PIC. TMBL version is 0.14.6.5

I haven't changed the exe at all ... I've only changed the FW on the PIC. TMBL version is 0.14.6.5

The address of the EEPROM is correct ... that HEX came straight from MPLABX ... and per the data-sheet, EEPROM on the Q43 is at 0x380000 (which is what's in the hex above). What did you change the address to? In poking through the code, it looks like the PC App is saying, "If the address is F0, then it's eeprom..." so, I modified the HEX to show the EEPROM data at 0xF0 (and updated the checksum to match) and it still failed ... it looks like it wants to write EEPROM (if the "Erase eeprom" is checked)...

As you can see: That hex file has both CONFIG and EEPROM data ... (although, I'd love a way to choose whether CONFIG bits are written) :020000040030CA :0A000000FFFFFFFFFFFFFFFFFFFF00 :020000040038C2 :080000004527CABADDCABADDCA :00000001FF

Well, we're in a couple of different threads here ... this particular thread relates to the PC App not sending CONFIG or EEPROM in the download...But, attached is a HEX file you can test with...

I posted my HEX in the other thread...and again, it works, but it's double-writing pages. If the PC application doesn't send 256 bytes per block...unless you've written some logic into your BL firmware to check for both 128B 'chunks' before writing a page? But in my testing, the first page written (0x00) is just 128B, as it's just updating the 0x00 instruction to launch the BL.