Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pic32mm and mk support #47

Open
cb88 opened this issue Jan 24, 2017 · 11 comments
Open

pic32mm and mk support #47

cb88 opened this issue Jan 24, 2017 · 11 comments
Assignees

Comments

@cb88
Copy link

cb88 commented Jan 24, 2017

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
Copy link

eerimoq commented Sep 12, 2018

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
Copy link
Owner

sergev commented Sep 13, 2018

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
Copy link

eerimoq commented Sep 13, 2018

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
Copy link
Owner

sergev commented Sep 13, 2018

OK, agreed.

@cb88
Copy link
Author

cb88 commented Sep 13, 2018

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
Copy link

eerimoq commented Sep 13, 2018

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
Copy link
Author

cb88 commented Sep 13, 2018

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
Copy link

eerimoq commented Sep 13, 2018

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
Copy link

eerimoq commented Sep 27, 2018

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 sergev self-assigned this Sep 27, 2018
@sergev
Copy link
Owner

sergev commented Sep 27, 2018

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

@eerimoq
Copy link

eerimoq commented Sep 27, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants