I have been having the same journey as this guy did back in 2015/2016. The mips_m4k.c target is faulty in it's fast programming part. The condition that enables the fast programming routine is clearly errornious, forgetting to compare the size - 1. Patching this is fairly straight forward.
However, with the condition is patched, there is another problem exposed:
See attachments to see exactly what I mean. The program_flash_to_write_to_chip.hex is what we want to write to the chip and program_flash_written_to_chip.hex is a flash dump from after trying to write.
As seen, byte 0x7F (128 bytes) is the last byte written in the 512 byte sized block. After that, the next 512 bytes are attempted to be written, but only the first 128 bytes are written. This smells like a hardcoded or math problem in the fast programming routine.
Please consult the chart below. Note that the raspberry pi numbers are the pin numbers. Not the GPIO numbers. The Board pin numbers refer to the Explorer 16/32 board PIM mapping pin numbers.
| BoardPin# | JTAGPinName | RPiPIN# | RPiPIN# | JTAGPinName | BoardPin# |
|---|---|---|---|---|---|
| PIN 18 | SRST | MCLR | |||
| P60 | TDI | PIN 19 | PIN 20 | GND | GND |
| P61 | TDO | PIN 21 | PIN 22 | TMS | P17 |
| P38 | TCK | PIN 23 | PIN 24 | Not Connected |