Skip to main content ↑ ↓
Topic: Bus Pirate PIC 24F Programmer Dev Thread (Read 44463 times) previous topic - next topic

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #30 –
[quote author="znanev"]
Guys,

sorry for kind of hijacking your thread, but can the algorithm for programming 18F26J50 be used to program 18F2550/18F4550 also? I have the latter chips laying around and would like to try to program them in LVP mode using my Bus Pirate.
[/quote]

znanev: we are working on a Bus pirate PIC programmer. The reason this chip gets more attention is it is used in the OLS and a couple of OLS are shipped without a bootloader. When we got flashing that controller working it will be fairly easy to extend it to other PIC controllers.

There is already some progress on the lower end PIC micro's (there are several topics in this development section) We are working on a new HVP adapter (almost done) and software support (prelimary CLI and binmode) support for it.

BTW no problem ;)

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #31 –
Thanks Sjaak for clarifying this :)

I have good knowledge of C# and could help extending the PIC programmer for the lower end micros. So I hope once the programming of the OLS's PIC is done, someone with more spare time could give some advices how the programming specification from the datasheet can be implemented in the PIC programmer's code :)

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #32 –
Just take a look at the datasheet and try to produce the same waveforms ;) The current pc-side programms use the raw2wire binmode to produce the waveform. In newterm (v5-alpha) there is also a dedicated binmode for pics (the lowend atm, hi-end on its way).

The binmode documentation is here: http://dangerousprototypes.com/2009/10/ ... wire-mode/ .

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #33 –
[quote author="znanev"]I have good knowledge of C# and could help extending the PIC programmer for the lower end micros.[/quote]The fastest code will be written in Standard C or PIC assembly, compiled to firmware, and run directly on the hardware.  You could script things remotely from a C# Windows program, but that source would not be very portable., and it would certainly be much slower.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #34 –
@znanev - To some extent, but the way they enter programming mode is different. The 18F2550 (12F/16F/18F, non -J parts) need a 13volt programming voltage. We have an adapter that can provide it, but it's still in prototyping and it will need software support too. The Bus Pirate will probably program these chips pretty soon because we use a lot of the USB PICs in projects and the goal is to program all DP projects with the Bus Pirate.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #35 –
***Still experimental. Tested by me on two OLSes, but YMMV. Use at your own risk!!!***

Here is a test package. The HEX loader isn't working yet, but I made a script that will program the whole bootloader. This worked, and verified against the original bootloader using an ICD2. Here's a quick screencast that shows how to use it:
http://www.whereisian.com/files/BP-OLS.swf

This package is probably the most complete to date, it contains:
*Latest Bus Pirate PIC programmer utility
*Scripts to read ID, erase chip, write OLS bootloader v1
*Firmware v4.3 required for Bus Pirate to work with PIC programmer app
*Latest firmware for OLS PIC (05/06) and bootloader app
*Latest test bitstream (2.04) and loader program
*New inf file for firmware 05/06

Process:
I. Load bootloader into OLS
http://www.whereisian.com/files/BP-OLS.swf
1. Update Bus Pirate with latest firmware. See:
http://dangerousprototypes.com/2010/01/ ... s-console/
http://dangerousprototypes.com/2010/02/ ... 30-loader/
2. Connect BP to OLS as previously described.
3. Start Bus Pirate PIC programmer application, choose the serial port and press the connect button to connect to the Bus Pirate.
4. Load readID from the script tab, OLS should return 0x02 0x4c.
5. Load the erase script from the script tab. The OLS PIC will be erased.
6. Load the OLS-BOOTLOADER-20MHz.scrp18 script. It will take a long time to program (minutes).

II. Load new firmware with bootloader
1.Put a jumper between the PGC and PGD pins, press the reset button. The bootloader starts and the ACT LED lights, the OLS enumerates as an HID device.
2. Run OLSv1-firmware-v06-20MHz.bat (or 05) to upload a new firmware to the PIC.
3. Remove the programming jumper

III. Load updated ROM with pump-loader
1. Hold the UPDATE button then press the RESET button to enter update mode. The ACT LED lights, and the OLS enumerates as a virtual serial port. If this is the first upgrade to v05/06 you will need to use the updated .inf included in the archive to assign a driver to the OLS.
2. Edit the load_ROM.bat file and modify the -p:COMx to match your system.
3. Run load_ROM.bat to load the updated bitstream to the OLS ROM chip.

Finish by unplugging the OLS from USB, then plugging it in again.

Complete package attached to this post.

***Still experimental. Tested by me on two OLSes, but YMMV. Use at your own risk!!!***
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #36 –
[quote author="rsdio"]
The fastest code will be written in Standard C or PIC assembly, compiled to firmware, and run directly on the hardware.  You could script things remotely from a C# Windows program, but that source would not be very portable., and it would certainly be much slower.
[/quote]

rsdio,

I can't agree with you that only Standard C or assembly can be used to program PICs. Even if you take a look at the code of the programmer discussed in this thread, you'll see it's written in C# and uses BP's raw write mode. Another thread also included a project in C# to talk to BP to program some lower end PICs. Other than that, yes, I can agree that if you make a programmer in assembly it will be definitely the fastest option. But also will be difficult to extend and maintain.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #37 –
@ian: you handcoded the script? :P

 Sjaak bows to ian

@znanev: I think rsdio ment that programming the Pic is C or ASM. The client can also be done in C/ASM or C#. However we also have customers with linux/bsd/osx/?? C# is not as common there (/me mumbles something about microsoft) Writing the client app in asm is useless IMHO because of the current processing power and the use of a 'slow' serial interface.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #38 –
The logic behind using the rawwire binary mode and a PC application for the PIC programmer is that each PIC has quirks, undocumented protocol requirements, etc. Integrating these into a single PIC firmware would take a lot of the space we need for other stuff, especially when v5 is released.

For a long time I swore never to add PIC programming at all, but just a few chips can't hurt, right :) We'll get it as fast as we can, but the Bus Pirate PIC programmer will probably end up like the JTAG support - good in a pinch, but pretty slow. And for me, I need a debugger for any real development anyways.

Hopefully, after we stabilize the code a little, someone will port it to a more multi-platform console-app situation.

For new protocols, we've found the best way is to implement the protocol as shown in the documentation, then capture the signals from an ICD2 working with the chip and figure out which parts are undocumented :p
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #39 –
Quote
@ian: you handcoded the script? :P

* Sjaak bows to ian

Only three pages (bootloader version, jump instruction, and config words). The main chunk of the firmware was output via a script :)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #40 –
[quote author="ian"]
The logic behind using the rawwire binary mode and a PC application for the PIC programmer is that each PIC has quirks, undocumented protocol requirements, etc. Integrating these into a single PIC firmware would take a lot of the space we need for other stuff, especially when v5 is released.

For a long time I swore never to add PIC programming at all, but just a few chips can't hurt, right :) We'll get it as fast as we can, but the Bus Pirate PIC programmer will probably end up like the JTAG support - good in a pinch, but pretty slow. And for me, I need a debugger for any real development anyways.

Hopefully, after we stabilize the code a little, someone will port it to a more multi-platform console-app situation.

For new protocols, we've found the best way is to implement the protocol as shown in the documentation, then capture the signals from an ICD2 working with the chip and figure out which parts are undocumented :p
[/quote]

I was looking for a nice picprogrammer for myself (besides my BP), and discovered a ICD3 will be out (or is out). The new model pics after 2011 (dunno the exact date from my head) will not be compatible with ICD2. Talking about Quirks ;) For most people, like me, just a programmer is sufficient (adding a serial debug is enough for me).

There is BTW a USBPICPROG firmware, but I dunno how usefull this is. I think the logic to deal with the quirks should be done at the client side (like it is done now). The buspirate takes care of supplying the Vpp, Vcc and 3v3 or 5v logic conversion. We have implemented some extras int the buspirate firmware to speed things up.

Using a script is a kind of cheating ;) (but soooo smart :P)

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #41 –
[quote author="Sjaak"]
@znanev: I think rsdio ment that programming the Pic is C or ASM. The client can also be done in C/ASM or C#. However we also have customers with linux/bsd/osx/?? C# is not as common there (/me mumbles something about microsoft) Writing the client app in asm is useless IMHO because of the current processing power and the use of a 'slow' serial interface.
[/quote]

Thank you Sjaak for clarifying this :) Now I see where the misunderstanding is - by "programming the PIC" in this case I meant putting the compiled HEX code into the code memory of the PIC, whereas rsdio had probably in mind the process of writing programs to be executed on the PIC.

So, please guys excuse me once again for interfering with this thread :)
 

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #42 –
Congraz, good to see that you got the programmer for the PIC18F26J50 working, finally.
With all the loop holes (unclear/incomplete and maybe even false information) in the
"PIC18F2XJXX/4XJXX FAMILY - Flash Microcontroller Programming Specification",
reverse-engineering became obviously the only option ...

Here is a picture of the connection between the BPs I/O header and the OLS' ICSP header
for programming the OLS with the Bus Pirate PIC Programmer (both the Bus Pirate and the
OLS are powered via USB!):

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #43 –
Woaah

This work's been a life-saver.
The procedure as described in ian's post worked for me.

The upgrade procedure for the BusPirate itself, however, could be clarified a bit more; but I'll admit it's a bit out of scope for this thread since the people that wanna play with this experimental functionality are most likely people that already re-flashed their stock v2-firmware-upon-delivery to the v4 firmware once already at least.
However, me, I bought a BusPirate and an OLS in one go; got them delivered at the same time and wanted to get cracking with the OLS; tough cookies because of boot-loader issues, the known story, by now. This meant that I got to face the learning-curve of dealing with the OLS and the BP and the multiple layers/levels of firmware upgrades of the PIC's, the Bootloaders of the PIC's and the Bitstream of the FPGA, all at once. Seems the only thing that didnt get a firmware upgrade so far has been the ftdi232rl ;)

Take this post to mean : Woaah, excellent work guys! Programming with the BusPiratePicProgrammer worked for me given the steps (and .swf) as demonstrated and i'm mighty grateful for it.

Having said that: some of the tools are only  available for Windows made things rather problematic for me.
Dragging my stuff to the office to play with it there on a loaner-PC seemed to be the only option. Kudo's for the multi-platform tools out there so far (pump-loader.pl, command-line BP-loader, etc); since i imagine a fair number of *nix-users are buying these products especially because of their open-source character and multi-platform tools, I imagine there's a fair number of people like me using these particular devices.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #44 –
For the moment the OLS saver is a windows app. This is because our developer developed it on windows, but it will be a matter of time before it is ported to the other platforms.

Great to hear it does work!