search

sergev / pic32prog

Flash programming utility for Microchip PIC32 microcontrollers
GNU General Public License v2.0
108 stars 52 forks source link

pic32mm and mk support #47

Open cb88 opened 7 years ago

cb88 commented 7 years ago

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.

eerimoq commented 6 years ago

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.

sergev commented 6 years ago

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.

eerimoq commented 6 years ago

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.

sergev commented 6 years ago

OK, agreed.

cb88 commented 6 years ago

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.

eerimoq commented 6 years ago

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.

cb88 commented 6 years ago

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.

eerimoq commented 6 years ago

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 commented 6 years ago

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.

sergev commented 6 years ago

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

eerimoq commented 6 years ago

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.