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?
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.
[quote author="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?
[/quote]
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
I would add to that, make sure that verify errors all occur outside of the bootloader address range. Other errors are not OK.
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?
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.
Alright, will do.
Thanks for the help!
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.
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
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/sv ... ippled.hex (http://the-bus-pirate.googlecode.com/svn/trunk/firmware/v2-nightly/BPv2go/v25-Firmware-v2.3-crippled.hex)
http://the-bus-pirate.googlecode.com/sv ... e-v2.4.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/ ... -problems/ (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
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
@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.
@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.
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.
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.
I wonder if there's a buffer overflow condition. The Bus Pirate has to spit out four bytes of ASCII for every byte of raw data, that could explain why it still works in raw mode.
I had a similar problem one time, but have not been able to reproduce it again. I'll keep investigating today.
I looked through the UART manual and found that the overflow bit halts RX until it's cleared. That can happen if the UART isn't open when data comes flooding in ([ or {), or if it comes too fast to translate to ASCII and shove up the USB connection:
http://ww1.microchip.com/downloads/en/D ... 39708B.pdf (http://ww1.microchip.com/downloads/en/DeviceDoc/39708B.pdf)
I added two new things to the latest nightly build for you to test:
http://code.google.com/p/the-bus-pirate ... v2-nightly (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v2-nightly)
First, byte reads will report the error bit status. If there are errors when you use r or {/[, then they'll show up like:
READ: -p -f -o 0xXX
-p is a parity error. -f is a framing error, and -o is a buffer overrun error. Once the -o flag is set, you can only read the bytes remaining in the buffer until the overrun flag is cleared. I think this is why you see the same byte after some time. Now if that happens and you see the -o flag, you know it's an overrun error.
Second, the overrun bit is now cleared any time you use the { or [ commands. If you close the live RX (]) and more than 5 bytes come in, use the r command and you'll see "READ: -o 0xXX", that means the error flag is active. Clear it by starting the live display again ({/[). Also, if there's an overrun during live display, you should be able to clear the error by stopping and starting live display (}{).
Okay, so poking around I noticed something interesting:
Output eventually (within seconds) hits 0x72 and sticks with mostly overflow errors:
--
READ: -o 0x72
READ: -f -o 0x72
READ: -f -o 0x72
READ: -o 0x72
READ: -o 0x72
--
If I clear the overrun with [ then the pattern continues - I get about 30 bytes of real data and then it sticks with the same pattern of errors.
If I change the data display format to raw, it seems to work without overflow - so it looks like you've pinpointed the problem.
The idea is to eventually have a big output buffer that can hold the terminal output while the UART is busy, that should help to some extent. 9600 seems pretty slow to have that problem, but I guess your source is going non-stop and it prints READ: plus the hex values for each byte and line feed twice (+4 characters).
Here's some issues I'd like to address:
1. How to handle buffer overrun in live display.
It's useless to display the same value and just report the error. It should probably show framing and parity errors, but announce and reset on overrun errors. "Bufferoverrun: input too fast, bytes dropped, try raw display mode".
2. Better data display
Is there a better way than writing each byte with READ: to a new line? Maybe just spit out the values if there hasn't been any user terminal activity?
3. Live/raw macro mode, input only bridge with reset?
Some way to watch fast raw data input and let the PC terminal do the hard work of displaying the value in whatever format. This could be like the bridge mode but no TX, press space to exit. Good for watching GPS output.
4. Clear overrun on transparent UART start
I need to clear the error bits before the macro starts so there's no problem after an overrun during other use.
In the latest v2go nightly:
Added overrun clear before bridge macro (should it clear automatically in bridge mode or report the error as repeated values?).
Added raw view as macro (2).
Overruns during live display and reads (r) are announced and cleared.