Problems after installing v2go firmware

[mastarg]

Hi!  I just got a v2go bus pirate from seeedstudio and installed the new v2.1 firmware.  The problem is...  It's still not responding to any serial commands! 

My serial setup seems to be ok, and it can connect fine to the bootloader in both the windows PIC utility and linux python script running at 9600 baud.  Aside from the verification error on the Windows utility, it flashed the hex file over the course of a few minutes.

I tried using cutecom and tera term at 115200, but no luck! 

The "mode" led is lit constantly after plugging it in. 

Does this mean it's stuck in bootloader mode for some reason (firmware not flashing correctly), or is there something wrong with my setup on the software side?

[ian]

I'm sorry your Bus Pirate isn't working. It sounds like the bootloading didn't complete.

At the very end of bootloading, when you press the green play button, it writes the new firmware start address to a special location. If that doesn't happen, then the bootloader will start next time instead of the firmware.

The bootloader also starts whenever there's a connection between the PGC and PGD pins.

It sounds like you've tried all the correct steps, please contact Seeed about a repair or replacement.

[dvbguy]

Hi!  I just got a v2go bus pirate from seeedstudio and installed the new v2.1 firmware.  The problem is...  It's still not responding to any serial commands! 

My serial setup seems to be ok, and it can connect fine to the bootloader in both the windows PIC utility and linux python script running at 9600 baud.  Aside from the verification error on the Windows utility, it flashed the hex file over the course of a few minutes.

I tried using cutecom and tera term at 115200, but no luck! 

The "mode" led is lit constantly after plugging it in. 

Does this mean it's stuck in bootloader mode for some reason (firmware not flashing correctly), or is there something wrong with my setup on the software side?

two suggestions make sure you do an erase first.. I didn't do it the firts time and I had some errors outside of the bootloader area, and make sure you press the green play button to do a mode switch

[ian]

I would add to that, make sure that verify errors all occur outside of the bootloader address range. Other errors are not OK.

[mastarg]

Ok, I'm on my linux box right now and I just tried using the Python bootloader.  It looks like there's a repeating pattern that fails verification at the very beginning:

Verification failed at 0x00000000: 0 != 4
Verification failed at 0x00000001: 4 != 12
Verification failed at 0x00000008: 255 != 28
Verification failed at 0x00000009: 255 != 111
Verification failed at 0x0000000A: 255 != 0
Verification failed at 0x0000000C: 255 != 28
Verification failed at 0x0000000D: 255 != 111
Verification failed at 0x0000000E: 255 != 0
Verification failed at 0x00000010: 255 != 28
Verification failed at 0x00000011: 255 != 111
Verification failed at 0x00000012: 255 != 0
Verification failed at 0x00000014: 255 != 28
(etc, etc)

After the repeating pattern ends the bootloader verification is skipped...

Then I get what seems to be a failure from the C00 area of the firmware to the very end:

Verification failed at 0x00000C00: 255 != 4
Verification failed at 0x00000C01: 255 != 12
Verification failed at 0x00000C02: 255 != 0
Verification failed at 0x00000C04: 255 != 0
Verification failed at 0x00000C05: 255 != 0
Verification failed at 0x00000C06: 255 != 0
Verification failed at 0x00000C08: 255 != 239
Verification failed at 0x00000C09: 255 != 192
Verification failed at 0x00000C0A: 255 != 33
Verification failed at 0x00000C0C: 255 != 0
Verification failed at 0x00000C0D: 255 != 127
Verification failed at 0x00000C0E: 255 != 34
Verification failed at 0x00000C10: 255 != 0
Verification failed at 0x00000C11: 255 != 1
Verification failed at 0x00000C12: 255 != 136
Verification failed at 0x00000C14: 255 != 0
Verification failed at 0x00000C15: 255 != 0
Verification failed at 0x00000C16: 255 != 0
Verification failed at 0x00000C18: 255 != 10
etc, etc.

The command I used for the programmer was:

python P24qp.py -s /dev/ttyUSB0 -a v25-Firmware-v2.1.hex -v

The -a arguement should erase, flash, and exit the bootloader.  The -v switch enables verification.

So something is definitely getting messed up during the bootloading process.  Any suggestions?  Maybe the bootloader needs to get reflashed from ICSP to properly program the firmware area?  Hardware failure?  Something else?

[ian]

I'm sorry your Bus Pirate won't bootload. It looks like it didn't erase properly, or the bootloader isn't working correctly. Could be a bootloader problem or a hardware erase problem. If you can erase and flash the bootloader, give it a try, otherwise contact Seeed for a repair.

[mastarg]

Alright, will do. 

Thanks for the help!

[mastarg]

I'm back to report great success! 

I managed to get my hands on a PICKit2 from microchip, reflashed the bootloader hex file and...  The bootloader now properly programs the firmware using the python programmer utility!

I connected using cutecom and everything seems to work perfectly now!  The mode light extinguishes after connecting the bus pirate, and it responds to commands according to the manual.

I'm not sure what was wrong with the bootloader, but reflashing it with an external programmer seemed to do the trick.  Maybe this will help somebody else who's having problems installing firmware on a v2go.

[geep]

It looks like I've had a similar problem, so I'll report it here..

My bus pirate seemed to work fine with the v2.2 firmware.. I did have encounter the uart issue (I just assumed I was doing something wrong). After upgrading to 2.3 the device became unresponsive to terminal input.

I reverted to 2.2, and it worked, but close examination of the log show similar verification errors.

This seems like a hardware issue, but would like to confirm with you.

---

$ ./P24qp.py -i -s /dev/ttyUSB0
Using Serial Port /dev/ttyUSB0 @ 9600
Reading 4 bytes from address 0x00FF0000
Found PIC24FJ64GA002
Reading Bootloader Version Information:
   Bootloader Version: 1.2

$ ./P24qp.py -e -s /dev/ttyUSB0
Using Serial Port /dev/ttyUSB0 @ 9600
Reading 4 bytes from address 0x00FF0000
Found PIC24FJ64GA002
Erase Flash:
   Erasing 43 pages, starting at 0x00000000
   Erase complete

$ ./P24qp.py -a v25-Firmware-v2.3.hex -s /dev/ttyUSB0 -v
Using Serial Port /dev/ttyUSB0 @ 9600
Reading 4 bytes from address 0x00FF0000
Found PIC24FJ64GA002
Erase Flash:
   Erasing 43 pages, starting at 0x00000000
   Erase complete
Writing 256 bytes to address 0x00000000
Reading 256 bytes from address 0x00000000
Verification failed at 0x00000000: 0 != 4
Verification failed at 0x00000001: 4 != 12
Writing 256 bytes to address 0x00000080
Reading 256 bytes from address 0x00000080
Writing 256 bytes to address 0x00000100
Reading 256 bytes from address 0x00000100
...
Skipping verification of bootloader area.
Writing 256 bytes to address 0x00000C00
Reading 256 bytes from address 0x00000C00
Verification failed at 0x00000C04: 255 != 0
Verification failed at 0x00000C05: 255 != 0
Verification failed at 0x00000C06: 255 != 0
Writing 256 bytes to address 0x00000C80
Reading 256 bytes from address 0x00000C80
...
Writing 256 bytes to address 0x0000A800
Reading 256 bytes from address 0x0000A800
Verification failed at 0x0000A8F8: 15 != 255
Verification failed at 0x0000A8F9: 0 != 255
Verification failed at 0x0000A8FA: 0 != 255
Verification failed at 0x0000A8FC: 0 != 255
Verification failed at 0x0000A8FD: 0 != 255
Verification failed at 0x0000A8FE: 0 != 255
Writing 256 bytes to address 0x0000A880
Reading 256 bytes from address 0x0000A880
...
Reading 256 bytes from address 0x0000AB80
Write operation complete.
Verified Okay.
   Verification complete, switching to user mode

[ian]

What terminal program are you using? Could you please test these nightlies to see if it fixes the problem:

http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v2-nightly/BPv2go/v25-Firmware-v2.3-crippled.hex
http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v2-nightly/BPv2go/v25-Firmware-v2.4.hex

I hate to make this suggestion, but is it possible to verify that you have the same problem when using the official Windows bootloader from Microchip? I've always gotten several random verify errors with the Python programmer.

My best explanation is here:
http://dangerousprototypes.com/2009/10/09/bus-pirate-firmware-v2-3-problems/

I'm sorry about the bug, I hope to have it fixed ASAP.
Could you

[geep]

I'm using minicom by default

2.3 - still doesn't work (of course), but trying other terms:
  screen /dev/ttyUSB0 115200 doesn't work
  hyperterm didn't work (after windows flash)
  Minicom doesn't work
  (may be of interest - interacting with the device after the flash util finishes (before hard reset) works fine anywhere)

2.3-crippled AND 2.4 AND 2.5
  -Menu works,
  -Serial doesn't work properly.
  -If I have used [, or { to read from the line, it gives bad data (eventually repeating the same value 0x72)
      -> if I then switch to uart bridge (1) then the same wrong data is given
  -If I switch immediately to bridge after startup it works perfectly
  -(tested windows flash, linux flash, different computers)

Also, I'm happy to say that the uart bridge mode now worked perfectly for me @9600 baud to another device

Aside, Some other things I've noticed for future reference of yourself and others:

The linux flasher (for me) _always_ fails on the first attempt:
--
Using Serial Port /dev/ttyUSB0 @ 9600
Reading 4 bytes from address 0x00FF0000
RX Error:  0  bytes received
   Error reading from device!
Device with ID: 65535 not listed in the config file!
--
But works fine if I try again.
Still seeing verification errors @ 0x0-0x1, 0xC04-0xC06 and 0xA8F8-0xA8FE

[ian]

@geep -

Yup, the 2.3 problem was due to a null byte in the UART buffer triggering the new binary access mode accidentally. I increased the number of 0's required to enter binary mode and it seems to have fixed the problem.

What settings are you using with the serial IO? (speed, databits&polarity, stop bits, RX polarity, and output type)
What is the source and voltage of the serial data?
Do you have anything else enabled like pullups, voltage regulators, etc?

Can you jumper the MISO and MOSI pins and test that data goes correctly between the TX and RX pins of the Bus Pirate itself?

I tested on the same Bus Pirate, and between two different version, without any problems. So it could be some settings that are still universally messed up. The output looks fine on a logic analyizer, so the TX side configuration should be working now. I don't have any other serial IO sources, but I'll try to pull something together.

[ian]

@geep - I can verify the RX problem.  I connected the a bus pirate to the RS232 converter on a v0 Bus Pirate.

* I can send characters to the PC fine @ 115200, but characters from the PC to the Bus Pirate are the same garbage character every time.
* I can send and receive fine at 9600. Could be a timing or crystal accuracy problem, but every single Bus Pirate works fine on UART1 at 115200 with the FTDI chip.

[ian]

Actually, now that I've switched back and forth between speeds on the Bus Pirate, and reset the serial port speed on the PC, I can RX and TX characters fine at 115200. Maybe there's a setting that's not working the first time.

[geep]

Okay, serial settings for pc to buspirate 115200-8n1
Serial settings from bus pirate to target:
9600,8n1,idle 1, normal outputs (3.3v)

Actions:
0 plug in device
1 set uart mode stuff
2 enter [
3 reset target device (router)
4 output spews crap, eventually sticking at 0x72

Tried: reseting using #, using { rather than [, setting buspirate to high bps and then reducing back to 9600. No effects.
I can't tell if the device in this config is receiving the sent bytes as I can't see the responses. I don't have another device to verify that 115200 works.

Immediately starting with bridge-mode rather than attempting to use individual reads works fine (i.e. substituting (1) macro in step 2)

Testing with mosi-miso works in all the modes I tested. I guess this could indicate a clock issue, but that doesn't explain why bridge-mode works.