Cannot upgrade buspirate; cannot use it either. Stuck.

[kbulgrien]

So I followed the FAQ to this point:

- use the new program (ds30loader or the commandline util) to upload a v4+ buspirate firmware

I cannot proceed past this point.  All attempts to program using the commandline utility fail at random points during the update attempt:

$ ./pirate-loader_lnx --dev=/dev/ttyUSB3 --hex=v4firmware/BPv3-Firmware-v4.1.hex
+++++++++++++++++++++++++++++++++++++++++++
  Pirate-Loader for BP with Bootloader v4+ 
  Loader version: 1.0.0  OS: Linux
+++++++++++++++++++++++++++++++++++++++++++

Parsing HEX file [v4firmware/BPv3-Firmware-v4.1.hex]
Found 21503 words (64509 bytes)
Fixing bootloader/userprogram jumps
Opening serial device /dev/ttyUSB3...OK
Configuring serial port settings...OK
Sending Hello to the Bootloader...OK

Device ID: PIC24FJ64GA002 [d4]
Bootloader version: 1,02
Erasing page 0, 0000...OK
Writing page 0 row 0, 0000...OK

...

Writing page 4 row 33, 1080...ERROR [4e]

Error updating firmware :(

Highest I have ever gotten is page 13.

I can no longer connect to it with a terminal...

[kbulgrien]

I don't understand why it says "Bootloader version: 1,02" as I did the bootloader update.

  $ python P24qp.py -a BPv3-v2blupdaterVa3-v4.1.hex -s /dev/ttyUSB0 -v

P24qp.py no longer seems to be able to talk to the buspirate re:

  $ python P24qp.py --config=P24qp.ini -s /dev/ttyUSB0 -i

Hopefully that means the bootloader is right.

[ian]

I don't understand why it says "Bootloader version: 1,02" as I did the bootloader update.

  $ python P24qp.py -a BPv3-v2blupdaterVa3-v4.1.hex -s /dev/ttyUSB0 -v

What parts of the upgrade were successful? Were you able to connect to the upgrader with a terminal, type 'yes', etc? Did the dialog indicate success?

Did you have any false starts, like trying to upload a v4 with p24qp? That will destroy the config fuses.

P24qp.py no longer seems to be able to talk to the buspirate re:

  $ python P24qp.py --config=P24qp.ini -s /dev/ttyUSB0 -i

The new bootloader app connects, so the old bootloader is gone. p24qp does not with the new v4 bootloader.

[Sjaak]

the bootloader version 1.02 is correct. We use a bootloader from a third party, and their version is 1.02. I agree that is it confusing, but this is what buspirate calls v4 bootloader (which actually refers to version of the main payload).

Errorcode 4e is checksumerror, could you verify the USB drivers or could you try to upload it with the mono version or a windows machine?

[kbulgrien]

What parts of the upgrade were successful?

Everything appeared to work correctly up to this fail point.

Were you able to connect to the upgrader with a terminal, type 'yes', etc?

Yes.

Did the dialog indicate success?

Yes. I cannot say I understood all the messages.  I went with "Success!" being adequate.

Did you have any false starts, like trying to upload a v4 with p24qp? That will destroy the config fuses.

I never attempted loading the v4 firmware with p24qp.  I did try loading the v4 bootloader many times with p24qp.py because I had many errors in the A8xx range and the instructions I had did not say they were okay.  Eventually I found the FAQ that said that was ok, so I started the whole process over and followed the FAQ step by step.

[Sjaak]

Errorcode 4e is checksumerror, could you verify the USB drivers or could you try to upload it with the mono version or a windows machine?

Could you give this a try? Also which upgrader.hex did you exactly run (please provide the exact filename)?

[kbulgrien]

the bootloader version 1.02 is correct. We use a bootloader from a third party, and their version is 1.02. I agree that is it confusing, but this is what buspirate calls v4 bootloader (which actually refers to version of the main payload).

Errorcode 4e is checksumerror, could you verify the USB drivers or could you try to upload it with the mono version or a windows machine?

Thanks.  I figured it was correct, but did not know how to reconcile v4 bootloader with a self displayed version of 1.02 when p24qp reported a version of 1.2 when I used the -i parameter.

I don't know what you mean by verifying the USB drivers.  How, and which ones?  I got RXTX from its website just last night.  All my other USB devices work... keyboard, mouse, thumb drive... and I was accessing the buspirate with the same system (self-test, etc.) via USB before I updated.  This operation is the first hint that something was wrong.

  libusb0.1_4-0.1.12-12mdv2009.0

I do not have a Windows license other than for Windows 98.  Even if I could, which I don't know, I would not load .net on it for various reasons.

My 32-bit system has only ICEwm (not a heavy IDE) etc.  Loading Mono on it is not something I want to do.  It is an Athlon 850 and does not need a bunch of heavy stuff on it.  I could try putting mono on my x86_64 system I guess - as this buspirate is a brick at the moment, but I've found that generally x86_64 is not where I want to go if I have trouble with 32-bit.  I am not a fan of GUIs with requirements like mono for doing low-level things like firmware updating.

[kbulgrien]

Errorcode 4e is checksumerror, could you verify the USB drivers or could you try to upload it with the mono version or a windows machine?

Could you give this a try? Also which upgrader.hex did you exactly run (please provide the exact filename)?

From command history:

python P24qp.py -a BPv3-v2blupdaterVa3-v4.1.hex -s /dev/ttyUSB0 -v

pirate-loader_lnx --dev=/dev/ttyUSB0 --hex=v4firmware/BPv3-Firmware-v4.1.hex

[kbulgrien]

Well, I pulled the BusPirate stuff over on to the 3.2 GHz i86_64 system and pirate-loader_lnx did just fine on it.  :-) No more bricks...

HiZ>i
Bus Pirate v3
Firmware v4.1 Bootloader v4.1
DEVID:0x0447 REVID:0x3043 (B5)

Sad day though when you need a space heater to blow a little firmware down onto a microcontroller... One would think 850MHz wasn't _that_ slow.

[kbulgrien]

BTW, these machines are the same distribution and version... the primary difference is that the slow box was 32-bit and the fast one was i86_64.

[Sjaak]

Ok, great! Welcome to the v4+ buspirate owners ;) Glad it did work out

I guess it was the speed, USB transfers keeps a cpu busy ;) Perhaps if your up to it you could try it with a cpumonitor running along it to check it. Or did you run some heacy program in the background?

With checking the driver i mean the kerneldriver for the usb2serial chip, since the error you got is a comms error (which could also be caused by a slow cpu)

[kbulgrien]

Slow system that failed:

# modinfo ftdi_sio | grep -v alias:
filename:       /lib/modules/2.6.27.37-server-1mnb/kernel/drivers/usb/serial/ftdi_sio.ko.gz
license:        GPL
description:    USB FTDI Serial Converters Driver
author:         Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>
depends:        usbserial,usbcore
vermagic:       2.6.27.37-server-1mnb SMP mod_unload 686
parm:           debug:Debug enabled or not (bool)
parm:           product:ushort
parm:           vendor:User specified vendor ID (default=0x0403) (ushort)

Fast system that worked (Core2 Duo):

# modinfo ftdi_sio | grep -v alias
filename:       /lib/modules/2.6.27.24-desktop-2mnb/kernel/drivers/usb/serial/ftdi_sio.ko.gz
license:        GPL
description:    USB FTDI Serial Converters Driver
author:         Greg Kroah-Hartman <greg@kroah.com>, Bill Ryder <bryder@sgi.com>, Kuba Ober <kuba@mareimbrium.org>
depends:        usbserial,usbcore
vermagic:       2.6.27.24-desktop-2mnb SMP mod_unload
parm:           debug:Debug enabled or not (bool)
parm:           product:ushort
parm:           vendor:User specified vendor ID (default=0x0403) (ushort)

Is the above what you mean?

During my troubleshooting I did consider CPU load.  In the beginning I had a stuck process that was filling up CPU, so I killed it and restarted X to get back to not having any load.  CPU load was negligible at start of upload.  I did not track the CPU load during the update process.  I guess now that I have the thing working again, I'm kind of not wanting to risk bricking it.  I just got the pirate yesterday after waiting almost a month for it.

IMO pirate-loader_lnx should not have to soak up all CPU, and that it could be made to be a little less demanding on a system even though USB is demanding.  Wonder if `nice` would have helped.  Putting in a few ms of sleeps at strategic points in the process might be worth considering.

[ian]

I'm really glad you got it working. I'm sorry my support wasn't much help. It was a problem with the pirate-loader on your system then? If you have any comments about the source, I'd be glad to pass them on to Piotr. I'll also let him know about this issue.

[kbulgrien]

@ian, I am not unhappy with your support.

If the following patch is applied to pirate-loader.c, the download works just fine on my slow PC.

Code: [Select]

$ svn diff
Index: bootloader-v4/pirate-loader/source/pirate-loader.c
===================================================================
--- bootloader-v4/pirate-loader/source/pirate-loader.c  (revision 313)
+++ bootloader-v4/pirate-loader/source/pirate-loader.c  (working copy)
@@ -458,7 +458,7 @@
                        }
                       
                        puts("OK");
-                       
+                       sleep(0);
                        if( g_verbose ) {
                                dumpHex(command, HEADER_LENGTH + command[LENGTH_OFFSET]);
                        }


[pppd]

Thanks for the fix, I will commit updated source and binaries in a few minutes.