Dangerous Prototypes

Dangerous Prototypes => Bus Pirate Support => Pirate PIC programmer => Topic started by: Jim on May 16, 2010, 01:21:24 pm

Title: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Jim on May 16, 2010, 01:21:24 pm
Since there isn't a thread (that I could find) about the recent blog posts I started this one.

Attached is a script to read the configuration words, you will have to remove the .txt extension and add a .scrp24 extension.

One thing to note is that the Programming Spec says that we should load CW2Address15:0 into W6 with the SIX instruction 2xxxx7 (2ABFC7 for the bus pirate's pic). This does not work and looking at the openprog source code the line should be 2xxxx6 (2ABFC6), which is logical since it's safe to assume that the last nibble defines the target register.

edit: WOOT! I have a script to write the configuration words up and running. You will need to modify lines 29 and 99 to suit your own purposes though and if bit 15 of the REGOUT doesn't clear by the end of step 8 add some duplicate step 8s to pad out the wait.

edit2: I did a couple more short scripts. One to demonstrate writing code memory and one to read code memory, but, due to the fact that my code that reads the scripts (I don't have a functioning bus pirate so I can't use the one in the dangerous prototypes repo), it just writes and reads the first 48 bytes of a table page.

So if you erase your chip with 7's script in the repo then run the attached ReadCodeMemory script you should read out 48 Fs. Then run the WriteCodeMemory script it will be programmed with 0123456789ABCDEF13579BDFFDB97531FEDCBA9876543210 starting at memory address 0x000200 which is the beginning of user flash program memory. Running the Read script again will read out the newly programmed code.

edit3: I just realized that to get this to work with the program in the repo you'll need to play with the timings. My programmer clocks the data in and out at 10ms per bit, which is really slow, but it works and rules out timing as a factor if any issues come up.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: gareth on May 25, 2010, 04:16:32 pm
I`m working on a Bus Pirate programmer for the 18F26J50, but having problems getting it to write to the chip.

I can read from any area of the chip, and also do a bulk erase fine, but can't get it to write at the moment.

I`ve looked at the released script for the 18F24J50, and tried running the one that writes to the chip, but thats not writing to the chip either.

Has anyone got any ideas? I wonder whether it's hardware related and if theres any special setup required for writing?
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Jim on May 26, 2010, 09:16:23 am
Hmm, I don't have any first hand experience with the 18f24j50's, but I can give you a couple of general pointers. Put NOPs between everything, seriously it's just easier to put NOPs everywhere than figure out what, exactly, does need a NOP or two. Also look at the source code of the OpenProg project, that also helped me a lot.

Having a 1 minute look at the programming spec vs the OpenProg code I can see that in their write function they use:
0x8EA6;
0x9CA6;

Instead of the:
0x84A6

From the data sheet, don't ask me why but it might help :P
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 26, 2010, 11:58:42 am
When I did the 24j50 write test with the write script (had to remove the \ comments, the current version of the app seems to report errors about them) I ran the erase script immediately before it. I don't know if that's key, but it was the procedure I used.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: IPenguin on May 29, 2010, 09:44:13 am
Considering the latest development in the OLS project (PICF24J50 based), this project deserves special attention because:

1. A considerable number of OLS boards shipped without a bootloader
2. Users need to upgrade the PIC18F24J50 firmware (at least they will have to install the bootlader) to be able to use recently released updates of the FPGA bitstream(s) - in particular because the latest releases fix bugs that made the OLS almost if not completely useless for a few users.
    Essentially, there is no way of msking use of any of the SUMP engine improvements since the interface between the PIC and the FPGA was changed and the firmware that shipped with the boards does not support the new interface
3. Some users seem to have no access to a PIC programmer with an ICSP interface but quite a few seem to have a Bus Pirate

I will take a look at the code now ... unfortunately I don't have the time to do any coding but I will test it on one of my OLS boards and provide feedback.

This appears to be an interesting project in general since it will be rather easy to support all MCUs of the PIC18F2XJXX/4XJXX family.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 07:13:21 pm
I was about to post an update, and noticed Jim's recommendation. We figured that out the hard way (logic analyzer), and kept the 0x84A6 too.  I eliminated that command and it gave me some limited success, but no luck yet.

The package attached has this stuff:
*Latest programmer executable
*v4.3 nightly firmware for PIC with new multi-bit command in rawwire
*scripts for read/write/erase
*hex dump from sametwice script

Here's where we're at:
Erase and read ID scripts work fine.
-firstokthentrash script programs 2 pages. It uses the commands mentioned by Jim + the datasheet command. It programs the first page OK, then programs trash to the second page. If you manually change the page address so the second and third pages are written, the second will be OK and the third will be trash, so it's not an addressing issue.

-sametwice script just uses the commands mentioned by Jim. It's a little more successful but programs the first page data to both pages, though the second page is a little off at the beginning and end. I included a dump of this in the script folder because this is the most successful so far.

7 has been working on this app, and I think at this point it should match the logic analyzer capture from the ICD2 pretty closely. I'll ask him to look at openprog and see if there's anything we can glean from there.

I have two questions at this point that require digging into a logic capture of the ICD2 -
1. Is only Jim's command used, or is 0x84A6 also used (seems more successful without).
2. In previous scripts we repeated step 1 (0x84A6) between every page write. The new script doesn't have it. Adding it just resulted in garbage.

These are fairly direct things to find out by looking at the logic capture, but it's tedious to count cycles. I'll see if I can at least answer 1 tonight.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 07:25:07 pm
The answer to #1 is both are used. Now to see if there's anything in between besides setting the table address.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 07:33:52 pm
The answer to #2 is no command but the table pointer setup is inbetween. The byte on the left is the last 0x0000 after the very-long delayed clock command. Then it immediately writes the 0x00 0x0E00 address setup command. Technically out script is doing everything right, now I need to check the output of Bus Pirate during programming to see what might be going wrong.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 07:46:33 pm
The Bus Pirate output looks a right, but immediately you can tell how much different it is using a serial interface than a clean USB interface. Each segment of the command is spread out. I don;t think it need to be quire this bad (command about 30ms apart), there might be a simple delay in the C program we can decrease. Also, we can use the PIC's 4byte hardware UART buffer to fill it up with the 3bytes needed for a command all at once. This will make the command happen with less delay between the segments, and we get around some of the USB latency too.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 07:55:19 pm
Here's the technically correct script.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on May 31, 2010, 08:04:41 pm
[quote author="ian"]
Here's the technically correct script.
[/quote]

You mean from the datasheet?

I love to see the final product!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 08:31:02 pm
haha :) No, the one that is from the logic capture of the ICD2 :) It has two commands that are undocumented in the spec :)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on May 31, 2010, 08:45:14 pm
Haven't looked very much into programming pic24f and up, but isn't it basicly the same as just sending the same commands as you would when programming it from the pic itself?  That could explain things?
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on May 31, 2010, 09:01:14 pm
The PIC24F is that way, I'm not 100% sure about 18f24j50. 7 is writing the code, maybe he can comment on the programming algo.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 01, 2010, 05:39:15 pm
Here's a new version. It programs the main chunk of the bootloader with the p18write.script18 script. It doesn't do the whole thing yet, it needs to write the page with the jump instruction at 0x800, and the flash configuration bits in the last page.

We didn't really figure it out, this is more of a cheat. We could write a single page after entering ICSP, so we enter ICSP, write a page, exit ICSP, and then repeat, for each page. Maybe after an initial release someone will figure out how to make a better algo with the scripting abilities and we can update it for even better speed.

The app has these updates:
*Now sends 3bytes (full PIC command + data) to Bus Pirate at once for more efficient use of USB packets. Vast speed improvement.
*New Auto Mode tab will select PIC, load HEX, and program.
*New write script writes main bootloader chunk.
*Connect also inits the Bus Pirate for programming (power supplies enabled, etc)

If you just want to test it out, the readID from datasheet script will read the ID from the Bus Pirate chip without changing or erasing anything. The connection from the Bus Pirate to the OLS ICSP header is MOSI->PGD, CLK->PGC, CS->VPP, GND->GND. You can power the OLS from the USB cable, or connect the Bus Pirate 3.3volt supply to the OLS 3.3volt pin of the ICSP header.

This version requires the updated firmware I posted previously.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 01, 2010, 05:42:23 pm
That archive also includes a logic capture in Saleae client format.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 02, 2010, 12:19:23 am
So I will try the read to test out my configuration.  It was unclear to me if you were suggesting testing more than that or not.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 02, 2010, 01:53:34 am
So I wired things, uploaded the nightly build you send out to the BP, and connected then I selected  the Pic18 Read device Id scrip and I get
Pinging Bus Pirate...
Running Script C:busPirateiolsupdateP18ScriptReadDeviceID from DataSheet.scrp18 ...
Entering PIC18 ICSP Mode!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0e3f!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef8!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0eff!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef7!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0efe!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef6!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0xfe!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0xfe!
Exit ICSP Mode!
Done!


This look good so far.  Is there any other test I should try at this point?
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 02, 2010, 02:17:59 am
While I am getting ahead of myself here, I went to collect the current state of files.  As far as I can see there is a V4 firmware, and V5 firmware and a V6firmware image, but I believe I need a bootloader image first.  So a link to that would be appreciated, as soon as it is wise to try to burn it.

Then is there a good reason not to jump to the V6 Firmware image and corresponding bitstreams?

I am assuming that the Pump.hex file out of the 2.04 firmware is the right bitstream to be testing here.  Is this correct?

So awaiting confirmatiion and a pointer to the bootloader hex file to load with the appropriate script file.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 02, 2010, 09:38:41 am
The pump.hex will be the firmware for the OLS (without the Bootloader) the bitstream to be loaded into the SPI rom is .mcs.

I don't know what will happen if loaded the .hex into the fpga ;) Are bitstreams protected by some kind of checksum?
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 02, 2010, 10:24:40 am
Thanks for giving it a test rhyde. It looks like there was a problem of some kind (connection from BP to OLS?). The OLS should return ID 0x02 0x4c:
Quote
Pinging Bus Pirate...
Running Script E:Workdp-svntrunkPIC24FProgrammerP18ScriptReadDeviceID from DataSheet.scrp18 ...
Entering PIC18 ICSP Mode!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0e3f!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef8!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0eff!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef7!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0efe!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef6!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0x02!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0x4c!
Exit ICSP Mode!
Done!

I'd check the connection to the OLS and that the OLS is powered @ 3.3volts during the connection.

There isn't anything more to test at the moment. We're almost there, there may be a full test today with the .HEX loader, or at least a full script that contains the bootloader. Once the 'auto' tab is finished you will be able to load the bootloader .HEX file from the project archive and program it, thus far we have only experimented with a scripted format to help figure out the algos.

Once you have the bootloader installed you're free to switch between firmwares and bitstreams.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 03, 2010, 03:23:31 am
Still getting the same results.  Here are a couple shots of the connections.  3.3 is from the bp, the rest as I understood the directions.  Is there some other jumper I need to get it to talk?  I was happy with a result that was not all 0s or 1s, guess there is another issue.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: IPenguin on June 03, 2010, 05:12:04 am
rhyde, did you install the [s:](as of now unreleased)[/s:] firmware v4.3 test [s:](BPv3-fimware-v4.3-test.rar)[/s:] BPv3-programmer-test.zip (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=550.0;attach=899)on your BP?

The Bus Pirate PIC programmer requires a modified raw-2-wire mode not available in the so far released BP firmware up to v4.2!

//EDIT// Just saw that ian released the BP firmware v4.3-test required for the Bus Pirate PIC programmer in BPv3-programmer-test.zip (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=550.0;attach=899)

I checked your cable connections between BP and OLS (on your pictures) - they are ok! You draw 3.3V from the BP, so it's ok that the OLS is not connected to USB for power.

For the OLS you should get either firmware v05 or v06 (both support SPI and work stable for me - I think it was robots, who reported for firmware v1.06 that the SUMP will not respond to commands which are sent within less than 2 sec after a capture is started  ... it doesn't really matter when using the Java SUMP client since you can't really issue a new command in under 2 sec from the client). Both are contained in OLSv1-firmware-v05v06-20MHz-b.zip (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=576.0;attach=880).

The correspondig bitstream to both firmware v05 and v06 is bitstream release 2.04 - 2.04TestRelease.zip (http://http://dangerousprototypes.com/forum/index.php?action=dlattach;topic=576.0;attach=816) contains PUMP.hex which is the correct release 2.04 bitstream (btw. release 2.03 does not include the Self Test!)

Quote
... but I believe I need a bootloader image first.  So a link to that would be appreciated, as soon as it is wise to try to burn it.

The OLS bootloader OLSv1-bootloader-v1.hex can be found in OpenBench_LogicSniffer_1.03.zip (http://http://www.gadgetfactory.net/gf/download/frsrelease/123/338/OpenBench_LogicSniffer_1.03.zip) ... however, please waite for further instructions by ian on how to install it with the Bus Pirate PIC programmer:

[quote author="ian"]
We're almost there, there may be a full test today with the .HEX loader, or at least a full script that contains the bootloader. Once the 'auto' tab is finished you will be able to load the bootloader .HEX file from the project archive and program it, thus far we have only experimented with a scripted format to help figure out the algos.
[/quote]
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 03, 2010, 08:05:39 am
I downloaded the nightly build Ian upload to this thread, and the script/programmer client doesn't complain.  If I switch the power arrangement do I have to do something to get the pic to listen to the programmer?  (Just trying to figure out what step I missed or and doing wrong.  I will post the BP startup info to be certain I have the right stuff.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 03, 2010, 08:22:20 am
Hmm I can't get the BP to respond to me via hyperterm on this system but the programmer does not seem to have a problem.  Does this firmware have a full UI?  Here is a portmon log attached, and renamed to .txt so the silly system would accept it.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 03, 2010, 08:29:41 am
Okay the problem is the power.  If I attach a second usb cable to the OLS to power it I get what I believe are the expected values.  The only difference is I powered it via USB this time.  So either the firmware is not bring up the 3.3, or the OLS is having issues with it.

Pinging Bus Pirate...
Running Script C:olsP18ScriptReadDeviceID from DataSheet.scrp18 ...
Entering PIC18 ICSP Mode!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0e3f!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef8!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0eff!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef7!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x0efe!
Sending 4-bit Command with Data: 0x00!
Sending 16-bit data: 0x6ef6!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0x02!
Sending 4-bit Command with Data: 0x09!
Sending 8-bit data: 0x00!
8-bit Data Read: 0x4c!
Exit ICSP Mode!
Done!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 03, 2010, 09:50:00 am
Thanks for the report. I'm glad you got it working, I'll check on the power supply issue. I used the BP supply at first, but then I made a special cable so I could connect the BP, ICD2, and logic analyzer at once without swapping probes between every test, and I've used the USB as supply since then.

v4.3 should respond to a terminal. It could be that the programmer app was holding the port open, or maybe it was left in binary mode and there was no ASCII interface.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 10:00:41 am
You could check the supply voltage in the buspirate with command 'v' (before running the scripts), I think the OLS would draw lots of juice.

I assume the pic has a undervoltage protection which assures proper writes in the ICSP mode.

@Rhyde: I assume you disconnect the BP powersupply? connecting two powersupplies to the same rail is tricky without a levelling circuit.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: IPenguin on June 03, 2010, 10:16:35 am
Looks like you have a working BP --> OLS configuration for programming the PIC18F26J50 on the OLS now :)

One way or the other, the PIC18F26J50 requires 3.3V on VDD while in ICSP mode ... either from the OLS' USB port/VR1 or from 3.3V on the BP's I/O header. However, make sure that you do NOT connect 3.3V from the BP's I/O header while the OLS is connected to USB and gets it's power from USB!!!!!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: znanev on June 03, 2010, 11:10:53 am
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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 11:32:37 am
[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 ;)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: znanev on June 03, 2010, 11:44:42 am
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 :)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 12:12:08 pm
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/ (http://dangerousprototypes.com/2009/10/27/binary-raw-wire-mode/) .
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 03, 2010, 01:14:13 pm
[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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 03, 2010, 01:41:12 pm
@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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 03, 2010, 03:21:35 pm
***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 (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 (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/01/22/how-to-firmware-upgrades-with-the-linux-mac-windows-console/)
http://dangerousprototypes.com/2010/02/ ... 30-loader/ (http://dangerousprototypes.com/2010/02/19/bus-pirate-firmware-updates-with-ds30-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!!!***
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: znanev on June 03, 2010, 03:55:38 pm
[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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 04:13:00 pm
@ian: you handcoded the script? :P

/me 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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 03, 2010, 04:20:17 pm
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
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 03, 2010, 04:21:35 pm
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 :)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 04:53:53 pm
[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)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: znanev on June 03, 2010, 04:59:05 pm
[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 :)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: IPenguin on June 03, 2010, 07:23:42 pm
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!):
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Insensitive_Clod on June 03, 2010, 10:54:44 pm
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.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 03, 2010, 11:14:44 pm
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!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 04, 2010, 01:46:41 am
Followed the steps, it worked, had a few scares.  Sjaak, are you going to pick up the new rawmode in new term, so I can have both?  I miss my newterm:-(
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 04, 2010, 09:10:19 am
Off course. You can speed it up by sending money ;)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 04, 2010, 11:17:48 am
Thanks for the reports guys, I'm gad it's working.

Actually Sjaak has some better handling for this stuff in the newterm branch, though we need to reconcile some things because the features of raw2wire are still needed for various weird things (hold data high at end of last write command, for example). Perhaps merging the newterm PIC commands (4/6 commands + data) into rawwire.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 05, 2010, 06:40:47 am
[quote author="Sjaak"]
Off course. You can speed it up by sending money ;)
[/quote]
But all my money is gone for wonderful new toys like this one.  I was just giving feedback on the things I noticed and the bootloader is very slow.  I am debating whether to leave the nightly on so I could help someone if necessary or going back to newterm so I can use it.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 05, 2010, 10:12:28 am
[quote author="rhyde"]
[quote author="Sjaak"]
Off course. You can speed it up by sending money ;)
[/quote]
But all my money is gone for wonderful new toys like this one.  I was just giving feedback on the things I noticed and the bootloader is very slow.  I am debating whether to leave the nightly on so I could help someone if necessary or going back to newterm so I can use it.
[/quote]

I wasn't serious when writing this. Sorry to offend anyone.

There is no reason to stick to the nightly if you don't want. (also no reason to switch back to newterm!) You must flash the version you want (or change when necessary) Flashing the BP takes only 10-20s so its quick. If you find tthis slow, please go back to the old bootloader at 9600 baud. ;)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 05, 2010, 11:13:54 am
Is it the OLS bootloader that's slow? How slow is it for you? FOr me it takes well under a minute, but not nearly as fast as the same bootloader in the USB IR Toy (seconds).

The problem is that the 18F24J50 has two write modes: 2bytes and 64bytes. A USB HID packet can only contain 64bytes, so once the header is included there's no room for a full page of data. What I did was convert the bootloader and the application to use the 2byte write mode. This is much slower than the original bootloader because only 2bytes go per packet (instead of 32 with the 18F2550 version). The eventual solution is to send 64bytes of page data over two packets, and set a write/flush flag on the second. The bootloader firmware actually already supports this, but I'm not much of a desktop programmer so I stopped with my first mods.

You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/binwire.c#164)

Thanks again for the upgrade reports. Admittedly it's a huge upgrade chain (BP, bootloader, firmware, ROM, etc). It's really encouraging that the first two upgrade seem to have been successful.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 06, 2010, 01:17:23 am
A note about USB: At the lowest level, certain types of endpoints are indeed limited to 64-byte packets. However, the same limitation is not present at higher levels. Both ends (host and device) understand that sending more than 64 bytes requires a sequence of as many 64-byte-packets as possible, followed by a 'short' packet that is 0 to 63 bytes to signal the end.

When programming the PIC, I believe that the USB library hides this detail from you. I wrote a USB Device Firmware Upgrade (DFU) firmware which works over USB with simple Control endpoint transfers. My PIC has the ability to write 1024 bytes, so I structured my DFU code to send 1024 bytes over USB in each step. My Mac client program made a single call for 1024 bytes, and my PIC firmware received 1024 bytes, but meanwhile the OSX USB drivers and the Microchip USB stack automatically dealt with the low level details of breaking this 1024-byte request into multiple 64-byte packets as needed. I didn't have to worry about that detail.

In other words, you could speed up your 18F24J50 FlashBurn by switching back to the 64-byte transfer, so long as you have full USB support. I can't remember whether you're using the Microchip USB library or a third-party solution, but either way this should be a very basic feature of USB.

P.S. For endpoints that have 32, 16, or 8 byte maximums, the process is the same. Maximum length packets are sent until the final packet which is shorter than the maximum, or 0 if the transfer divides evenly into the max length.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 06, 2010, 10:16:15 am
We're using a modified version of the Diolan USB HID bootloader, written in ASM. It uses raw 64byte HID packets. As far as I know, it does not currently support transparently breaking apart large data transfers into smaller packets. I could be totally misunderstanding how it works though.

Before I dug into the guts of the utility and firmware to get it working, I just modified the data length and tried to send larger packets without success. I did leave a way to break larger transfers into smaller chunks so something similar to what you described is already supported by the current firmware. I've just not updated the PC to support this yet.

Ultimately, I'd like to port the LUFA open source USB CDC-serial (ACM) stack and CDC-serial bootloader to the OLS (and PIC in general). The Windows application for HID transfers requires a massive amount of system setup to compile, and it has a huge number of source files for a simple console app. I really prefer simple serial bootlaoders because the apps are easy to write, and bootloaders can be made in scripting languages like Perl and Python.

http://www.fourwalledcubicle.com/LUFA.php (http://www.fourwalledcubicle.com/LUFA.php)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 06, 2010, 11:02:55 pm
[quote author="ian"]
You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/binwire.c#164)
[/quote]

I added it to newterm for now to keep up with the normal release. It is in the other topic ( http://dangerousprototypes.com/forum/in ... opic=291.0 (http://dangerousprototypes.com/forum/index.php?topic=291.0) )

BTW: should the reply to 0x01 (get id) not RAW2 instead of RAW1? I know the first concern is to help the people and get most of the OLS's (OLSes?) into working order.
BTW2: forgot to add something (0x4x) to the svn? :P
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 07, 2010, 01:39:32 pm
Yeah, that's probably a good idea to up the number. Thanks for adding it v5. I'll cross it off the list on the other thread.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 07, 2010, 06:01:24 pm
We should just have one reply to the entire PIC command of three bytes to speed up the time between bus writes.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 08, 2010, 11:02:04 am
[quote author="ian"]We're using a modified version of the Diolan USB HID bootloader, written in ASM. It uses raw 64byte HID packets. As far as I know, it does not currently support transparently breaking apart large data transfers into smaller packets. I could be totally misunderstanding how it works though.[/quote]I got the impression from reading the USB spec that this is required. I suppose that still doesn't guarantee that Diolan implemented it. The feature would certainly be at a higher level, because individual packets are limited in length. Perhaps HID never allows more than 64, and so Diolan skipped the higher-level feature altogether. Something like Microchip's USB stack, which must support more than just HID, handles this for you. Then again, even Microchip has a separate bootloader implementation of their USB stack, and it is stripped down.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 11, 2010, 07:17:55 am
The upload to the OLS once the bp had loaded the bootloader on it was extremely slow.  The progress print out incremented, but so slowly I was wondering if it was working.  (That is why I mentioned it, as it could cause someone to abort.)  I mean more than a couple of minutes I would say 5 to 10 seconds a chunk is what I observed.  It was not intolerable, but it was as I said slow enough I was worried it was not working.  The BP upload was not blindingly fast, but it was not ridiculously slow.  It was about what I expected, probably output limited on the display.  The OLS bootloader was the one that was very slow.  I do not know how big the the pic image is, but those things do not have that much memory, and it was slow enough it could have been timeouts IMHO.  Fortunately it was not.

(Sjaak, I was just kidding back.  I am not one to take offense.)

[quote author="ian"]
Is it the OLS bootloader that's slow? How slow is it for you? FOr me it takes well under a minute, but not nearly as fast as the same bootloader in the USB IR Toy (seconds).

The problem is that the 18F24J50 has two write modes: 2bytes and 64bytes. A USB HID packet can only contain 64bytes, so once the header is included there's no room for a full page of data. What I did was convert the bootloader and the application to use the 2byte write mode. This is much slower than the original bootloader because only 2bytes go per packet (instead of 32 with the 18F2550 version). The eventual solution is to send 64bytes of page data over two packets, and set a write/flush flag on the second. The bootloader firmware actually already supports this, but I'm not much of a desktop programmer so I stopped with my first mods.

You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164 (http://code.google.com/p/the-bus-pirate/source/browse/trunk/source/binwire.c#164)

Thanks again for the upgrade reports. Admittedly it's a huge upgrade chain (BP, bootloader, firmware, ROM, etc). It's really encouraging that the first two upgrade seem to have been successful.
[/quote]
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 11, 2010, 09:36:49 am
The way to write a pic18f or pic24f is different then the lowerend pic. You need to send a lot bytes just to programm one programword. With the lower end it is just 3/4 bytes to program just one programword.

The icsp is just pratical for uploading a bootloader. Suppose you need to upload 256Kb ;) zz.. ..zzZZzzZzZZZz
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 11, 2010, 10:20:56 am
Quote
I do not know how big the the pic image is, but those things do not have that much memory, and it was slow enough it could have been timeouts IMHO.

This chip especially is tiny (4K words, 8Kbytes), and we only program a small portion with the current firmware.

Just in case, here is a screencast of my update process. Is it comparable to your speed? Actually timing it with the recorder I can see it's only about 20 seconds, that's a lot less than what you're reporting. I wonder if it's a bug somewhere.

http://www.whereisian.com/files/ols-bootloader.swf (http://www.whereisian.com/files/ols-bootloader.swf)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rhyde on June 12, 2010, 02:59:51 am
No that video is 10x the speed I had.  I will have to do it again with a stop watch or timer going.  I would not have mentioned that speed.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 12, 2010, 08:34:27 am
@rhyde - thanks for the update. Maybe it's a bug we can work out.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: IPenguin on June 13, 2010, 07:36:07 pm
I have used the bootloader repeatedly during tests with the prototypes (before the preorder OLSs shipped) and with preorder OLSs and found the process rather slow myself. So I repeated loading OLSv1-firmware-v06-20MHz.hex with the bootloader again:

Here is the "stop watch timer":

(http://http://img812.imageshack.us/img812/6953/firmwarev06update.png)

20,18 sec ... while the progress counter was steadily increasing ... a few percent per second. This is about the same speed I get with the BP v4 bootloader ...  however, the total upload time for the BP firmware (v4.5) is about 10 times longer as it is roughly 10 times the size of the OLS firmware v06 (hex files: OLS 24 KB - Bus Pirate 237 KB)

[quote author="rhyde"]
The upload to the OLS once the bp had loaded the bootloader on it was extremely slow.  The progress print out incremented, but so slowly I was wondering if it was working.  (That is why I mentioned it, as it could cause someone to abort.)  I mean more than a couple of minutes I would say 5 to 10 seconds a chunk is what I observed.  It was not intolerable, but it was as I said slow enough I was worried it was not working.  The BP upload was not blindingly fast, but it was not ridiculously slow.  It was about what I expected, probably output limited on the display.  The OLS bootloader was the one that was very slow.  I do not know how big the the pic image is, but those things do not have that much memory, and it was slow enough it could have been timeouts IMHO.  Fortunately it was not.[/quote]
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 15, 2010, 09:25:15 am
It looks like Ipenguin had something similar to me, much less than 5-10second/chunk (8-10minutes?). No matter the cause, the situation would be vastly improved by sending more data per USB packet.

Do you have another device on the USB bus that takes priority and generates a lot of traffic - a USB sound device (speakers or headphones) maybe?

My current plan is to build a new, 'standard' bootloader based on serial protocol so the app is easier to work with. We're working on the teensy USB stack in another thread.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 15, 2010, 10:08:01 am
There's a new package at google code with executable and source for the latest version. It's .net but also targeted to linux/mono, so it should work there too. It includes the HEX parser. It can ID, erase, and program the 18f24j50, with lots of testing completed successfully. It also has 18F and 24F script modes for debugging/prototyping other chip protocols.

http://code.google.com/p/the-bus-pirate ... UN2010.zip (http://code.google.com/p/the-bus-pirate/downloads/detail?name=PiratePICprog.15JUN2010.zip)

I'll post an OLS rescue package and instructions next.

Getting the project started and the OLS rescue out was the most important goal so far. Now that a couple of us have an idea of the scope of a PIC programming app, we should try to regroup a little.

I'm stuck between continuing to use a raw2wire-based programmer, or implementing a PIC mode. I added a 4/16bit extension to the current nightly firmware, but maybe this should be planned a little better. Maybe it would be easiest to use the usbPICprog source as a mode or separate firmware, even if we have to write our own serial application. znanev has worked with the usbpicprog source lately, I'll ask if they have any thoughts.

What about moving future development to ming or something and make a console application? It would be a lot more portable, and use open source tools.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 15, 2010, 10:21:01 am
My suggestion is this: Don't forget those of us who have an actual PICkit programmer.  So far, I haven't needed to change any firmware, but when I looked into the IR Toy update, I couldn't find a single firmware image that was ready for the PICkit.  There were options for USB programming, but even those seemed incompatible with each other (I found several images).

I'm not sure what to suggest, since it can be difficult to mix PICkit programming and USB programming, but I'm merely suggesting that you consider those of us who have the equipment for full-speed programming.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 15, 2010, 10:41:19 am
There are several ways to go:

- Port the usbpicprog to a (seperate) firmware.
- Extend the current app with some scripting for lower end pics.
- write a new app (preferable in C/C++ to make it (more) platformindependable).

I prefer one of the last two options; The Buspirate is ment to be a all-round swiss army knife. This way the most options (without ruling out others) are in just one firmware and (also important) one codebase ;)

I think there is need for a special binmode since it is a strict protocol (see the timing issues some people expirience). On the other hand the rawwire could profit of sending multiple bits/byte in one go (there was a discussion about that in the newterm topic (?) some time ago).

@rsdio: the buspirate makes electronics reachable/understandable for the masses. It is ok for people who want to occasional program a chip.

I don't have a PICkit (yet) but I guess the .hex can be directly uploaded by the PICkit?

Edit: post 500!!!  \o o/ o//

/me gave you a virtual drink.. Enjoy!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 15, 2010, 11:00:48 am
Quote
So far, I haven't needed to change any firmware, but when I looked into the IR Toy update, I couldn't find a single firmware image that was ready for the PICkit.

The IR Toy firmware is ready to program into the chip without a bootloader, it works either way. The bootload-able firmware contains jump instructions at the 0x8 and 0x18 interrupt vectors that redirect them to the relocated vectors in the firmware. This is not true of the Bus Pirate (yet...) but it is the case with the IR Toy, OLS, and Flash Destroyer. This 'feature' is actually what caused the bootloader-less OLSes to go unnoticed.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 15, 2010, 11:01:56 am
Congrats on 500 posts!
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: sevenstring on June 15, 2010, 11:17:43 am
;D :D :D ;D
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 16, 2010, 12:21:28 am
[quote author="ian"]
The IR Toy firmware is ready to program into the chip without a bootloader, it works either way. The bootload-able firmware contains jump instructions at the 0x8 and 0x18 interrupt vectors that redirect them to the relocated vectors in the firmware. This is not true of the Bus Pirate (yet...) but it is the case with the IR Toy, OLS, and Flash Destroyer. This 'feature' is actually what caused the bootloader-less OLSes to go unnoticed.
[/quote]
I'm probably being too picky, but what you describe would remove the ability to upgrade the firmware via USB, wouldn't it?  I was hoping for a way to program both the USB bootloader and the new firmware together.  I guess you could say that I want my cake and to eat it, too.  I did not want to end up with a bootloader-less IR Toy, because I might be off somewhere with my laptop and no PICkit.

I'm not saying there is an easy fix for this.  I tried manually merging the IR Toy bootloader image with the upgraded firmware, by staring at the raw hex (and using a hex disassembler that I wrote), but there were some incompatibilities.

@Sjaak: Of course you guys are all doing great work to support people without the PICkit or similar commercial programmers.  I think it's awesome that DP makes the BP and it can program the other DP products.  All that I am suggesting is that this effort not end up making regular fast programming any harder.  I guess that means coming up with procedures for combining the bootloader and firmware updates so that the programmer can maintain both of them instead of erasing the bootloader during an upgrade.

One thing to keep in mind is that the programmers seem to always erase the entire Flash.  In contrast, the bootloader can erase some blocks and leave other blocks untouched.  That makes it a challenge.
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 16, 2010, 08:07:01 am
Quote
...would remove the ability to upgrade the firmware via USB, wouldn't it?

I see, yes, programming the firmware directly like that does erase and remove the bootloader.

Quote
I was hoping for a way to program both the USB bootloader and the new firmware together.

This should be totally possible. I'm not sure of the .HEX foo required to to merge the files, but I provide a dump to Seeed with bootloader+firmware in one, for example, so it's possible to build an all-in-one. The problem might be that it doesn't play well with the bootloader then because certain vectors are already relocated, but if the bootloader PC program was smart enough to ignore the bootloader section, then maybe that can be worked out too.

On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: rsdio on June 16, 2010, 08:48:26 am
[quote author="ian"]On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)[/quote]This is an excellent question, but potentially a deep topic, so I've created a new thread in the general category: (Intel) .HEX reader/writer/editor (http://http://dangerousprototypes.com/forum/index.php?action=post;board=2.0)
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: Sjaak on June 16, 2010, 09:12:26 am
[quote author="ian"]
Quote
...would remove the ability to upgrade the firmware via USB, wouldn't it?

I see, yes, programming the firmware directly like that does erase and remove the bootloader.

Quote
I was hoping for a way to program both the USB bootloader and the new firmware together.

This should be totally possible. I'm not sure of the .HEX foo required to to merge the files, but I provide a dump to Seeed with bootloader+firmware in one, for example, so it's possible to build an all-in-one. The problem might be that it doesn't play well with the bootloader then because certain vectors are already relocated, but if the bootloader PC program was smart enough to ignore the bootloader section, then maybe that can be worked out too.

On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)
[/quote]

If you copy two .hex in just one file (remove the end of file indicator from the first) the programmer will fix it. The order is important (last file wins), but perfect doable.

So I would say notepad rules! :P
Title: Re: Bus Pirate PIC 24F Programmer Dev Thread
Post by: ian on June 17, 2010, 06:11:16 pm
I moved this to a new PIC programmer sub-forum. I also started a new cross-platform console version of this app that compiles with GCC/MinGW. It currently IDs, erases, and programs a single page. Updates are here:
http://dangerousprototypes.com/forum/in ... opic=650.0 (http://dangerousprototypes.com/forum/index.php?topic=650.0)