pic32prog icon indicating copy to clipboard operation
pic32prog copied to clipboard

pic32mm and mk support

Open cb88 opened this issue 8 years ago • 11 comments

It seems pic32mm is slightly different and uses a different PE. But the pickle utility can already program it apparently in slow mode (direct write without the PE). It seems that pickle is GPL3.

It would be nice if pic32prog also could do the same.

cb88 avatar Jan 24 '17 20:01 cb88

Hello,

... 1.5 years later ...

I've been designing a PIC programmer recently, pictools, which supports the PIC32MM0256GPM064 family. It's based on an Arduino Due. If you are still interested in finding a programmer and has an Arduino Due nearby you can give it a try =)

I've used two Arduino Dues when testing it, and unfortunately only one of them works with a 460800 baud rate UART towards the PC. The other works with 115200. I'm planning on using the native USB port on the Arduino Due instead of the UART, which should make the transfer rate towards the PC a non limiting factor, eliminating the UART baud rate problems altogether.

eerimoq avatar Sep 12 '18 21:09 eerimoq

Hi Eric, Wow, as I can see, you even have implemented a custom PE! That's amazing. I need to try to reuse your code. It would be good to replace Microchip PE binaries with opensource versions. Your programmer with the native USB port would be an excellent tool. I can add a support for it to the pic32prog.

sergev avatar Sep 13 '18 04:09 sergev

You're right, I implemented a custom PE to allow faster programming using a slightly different protocol between the Due and the PIC32. At least that is the goal. I also cut the PE download time in half by using the SWM32 instruction storing 10 words (32 bits each) at a time instead of one word at a time as described in the flash programming document from Microchip.

Writing zeros to a 262k PIC32MM flash takes about 7.2 seconds. That includes chip erase, PE download and writing to flash. Hopefully the same operations using USB instead of UART will take less than 5 seconds, which is pretty fast.

The protocol between the PC and the Arduino Due is not yet finalized and could be partly redesigned in the near future. I do not recommend you to add support for this programmer in pic32prog yet due to this. I can let you know once it's ready.

eerimoq avatar Sep 13 '18 05:09 eerimoq

OK, agreed.

sergev avatar Sep 13 '18 06:09 sergev

Actually i don't have an Arduino Due (Just Arduino stock, Pro Nano, Leonardo, Lenny etc... ), but thanks for working on this and it seems like it will be useful with other boards also since you implemented a PE. Would be nice if it were compliant with Microchips PE programming standards though. Even if it were a bit slower. Programming devices in parallel from one programmer would be really cool also.

cb88 avatar Sep 13 '18 19:09 cb88

In the current programmer implementation PGEC, PGED and MCLRN are hard coded to Arduino Due pins D2, D3 and D4. It would be trivial to let the PC select pins instead, allowing many devices to be connected to the same programmer. Then the devices can easily be programmed in sequence.

Is that what you mean, or do you really mean programming many devices in parallel? I mean, what is the advantage of parallel programming compared to what I described above? I can't think of any.

eerimoq avatar Sep 13 '18 19:09 eerimoq

Well in sequence would still be useful, but programming the same exact image simultaneously would be that much more useful as it would only require the data to be transmitted over USB once, but to N devices instead of just one.

the normal one device at a time might take you 5 min, connecting 10 devices and hitting program would get you down to about a minute per 10, doing them simultaniously would get you down to 10 seconds clearly dominated by the time it takes to connect the devices.

cb88 avatar Sep 13 '18 20:09 cb88

Well, bit banging the ICSP protocol is likely the bottleneck, not USB, neither the PC. Bit banging many devices in parallel is hard to implement and will likely not increase the throughput much, if at all. My guess is that it just adds overhead and makes the programming slower. The only feasible usage of the pictools project is to program the devices in sequence.

eerimoq avatar Sep 13 '18 21:09 eerimoq

The PE and programmer protocols should be fairly stable now. Here are the specs in case you are still interested in using them:

Ramapp (PE): https://github.com/eerimoq/pictools/blob/master/ramapp/README.rst Programmer: https://github.com/eerimoq/pictools/blob/master/programmer/README.rst

Have a look in the source code as well for completeness.

eerimoq avatar Sep 27 '18 18:09 eerimoq

Thank you, Eric! I've got a few pic32mm chips, so I can try it.

sergev avatar Sep 27 '18 18:09 sergev

Ohh, and the ramapp upload instructions can be found here: https://github.com/eerimoq/pictools/blob/master/programmer/ramapp_upload_instructions.i

I used CrossTool-NG to build the MicroMIPS cross compiler. I'm not using XC32. If you need the unmodifed ramapp srec/hex-file I can build it and add it to the repository.

eerimoq avatar Sep 27 '18 20:09 eerimoq