Skip to main content ↑ ↓
Topic: problems loading BP3 firmware 3 (Read 4405 times) previous topic - next topic

problems loading BP3 firmware 3

problems after installing V3

Hi,

after the delivery of BP today, everything appeared to work, including self test. and access to the command line IF was made using screen /dev/tty.usb* 115200
this worked
I then tried to update to v3 using the python installer, everything went well but upon retrying the BP I don't get an output on the command line.

I have 2 BP, both in the same delivery and I have only tried to update one so far (and failed) so the other is on hold until the source of the problem is identified). In both cases when shorting the PGC and PDC pins the MODE LED does NOT light up?
(FYI in the self test mode - the check reports the MODE LED to be working)

I have tried to run the python script in auto-mode (-a) with what appears to be success, and reading some of he comments with v2go problems I have also tried to run first with erase (-e) first then run afterwards with write (-w) with success but still no command line output

What am I doing wrong or if this a problem with some bp3 boards?

unfortunately i do not own a pickit /programmer to retry to load the bootloader ?

transcript from the last loading below:
minimac:BusPirate-1 minimac$ python P24qp.py -e -s /dev/tty.usbserial-A600aS5d
Using Serial Port /dev/tty.usbserial-A600aS5d @ 9600
Reading 4 bytes from address 0x00FF0000
Found PIC24FJ64GA002
Erase Flash:
   Erasing 43 pages, starting at 0x00000000
   Erase complete
minimac:BusPirate-1 minimac$ python P24qp.py -w v3-Firmware-v3.0.hex -s /dev/tty.usbserial-A600aS5d
Using Serial Port /dev/tty.usbserial-A600aS5d @ 9600
Reading 4 bytes from address 0x00FF0000
Found PIC24FJ64GA002
Starting write operation...
Writing 256 bytes to address 0x00000000
Writing 256 bytes to address 0x00000080
Writing 256 bytes to address 0x00000100
Writing 256 bytes to address 0x00000180
Writing 256 bytes to address 0x00000200
Writing 256 bytes to address 0x00000280
Writing 256 bytes to address 0x00000300
........
........
Writing 256 bytes to address 0x0000AA80
Writing 256 bytes to address 0x0000AB00
Writing 256 bytes to address 0x0000AB80
Write operation complete.

UPDATE- some sniffing around with a MM.
I probed the pins on both boards and there is a voltage across the MODE LED pins (3.3v) whenin firmware update mode, PDGC-PDC pins are shorted; and in both examples of board the MODE LED is dead!

Also the USB LED doesn't burn as brightly as it did in the first 5 minutes?
resistors for PWR and USB are 1KΩ, whereas MODE and VREG are 390Ω

Re: problems loading BP3 firmware 3

Reply #1 –
I'm really sorry you're having upgrade problems. So you are able to successfully connect to the bootloader and upgrade, but you can't connect with the terminal? It looks like you're doing everything right, but I don't use the Python updater. If possible please try the 'official' Microchip Windows updater utility.

What terminal do you use? The recent firmwares have a binary mode, some MAC users have reported that their terminal sent AT modem commands that accidentally enter binary mode. Does it work if you downgrade to a previous firmware? (<2.4) Do you have all flow control disabled?

http://code.google.com/p/the-bus-pirate ... nloadCount

PWR and USB are 5volt powered, MODE and VREG are 3.3volt powered, that's why the resistors are different. The self-test just verifies that the pin works, not that the led is actually shining.

I suspect your MODE LEDs don't work because they're installed backwards. There should be a tiny green strip on the side of the LED that faced the I/O header. I had another report of that this week too. It seems to be limited to Bus Pirates delivered in the past week, I don't know the extent of the problem. I've written to Seeed and asked them to look into it.

It is also possible that the bootloader was damaged or you have a defective chip.
Got a question? Please ask in the forum for the fastest answers.

Re: problems loading BP3 firmware 3

Reply #2 –
Hi Ian
OK I switched to a PC :( other than COMDLG32.OCX being missing from the system32 directory I was able to start up the pic installer.

Went through the process as described in READ.ME and everything appeared to work, i.e. the device was found upon connecting to it and uploading the firmware, other than inspecting the HEX bits it looked like it was writing the file.

again it doesn't work.

I then tried with the other BP, and this loaded successfully

The difference in the two experiences is with the non loadable BP, when you click on ERASE in the PIC.EXE the process of erase is instantaneous, (too instantaneous if you know what I mean), whereas on the working BP, ERASE takes a small duration of time. Other than that the process appears identical.

Further info:
if on the non working BP, I fail to connect PGD-PGC then I try to connect to the device in the pic EXE, it fails. That makes me assume that the bootloader is behaving?

LEDS
I unsoldered one and turned it around after my 1st post and it still didn't work. With a multimeter I was able to get a reading in diode mode with the test probes either way, I would think in one direction we would have a open circuit/hiZ?

what function illuminates the VREG LED? (update- ok found it IC2 turn on power supplies)


All in all, I now have one BP at V3 and one that is like a parrot nailed to a perch!
and mode leds failed on both boards


As for MAC OSX, I've been using 'screen' from the terminal, I've also had favourable results with coolTerm,
If using coolTerm set options for 'Enter Key Emulation ' to 'CR', default is CR+LF which does not work!

screen works a charm with v3 firmware too!

Re: problems loading BP3 firmware 3

Reply #3 –
It sounds like one of the Bus Pirates has a bad PIC chip, please contact Seeed for a replacement.

Screen and coolterm should both work, Zterm gives the most problems. Here's my writeup on Coolterm configuration:
http://dangerousprototypes.com/2009/10/ ... x-windows/

I'm not sure about the LEDs. The MODE LED should light when you enter the bootloader, and it should light when you select a mode in the user terminal (for example 'm' and then 2). If they're not backwards they may be defective, odd that you have two defective LEDs on two boards and they're not reversed, but both are MODE LEDs.
Got a question? Please ask in the forum for the fastest answers.

Re: problems loading BP3 firmware 3

Reply #4 –
Hi Ian
Just to inform you and others that might be experiencing similar problems, I got in touch with Seeedstudio and they're going to organise a replacement BP and some LEDs to repair the busted ones.

good news all round

Re: problems loading BP3 firmware 3

Reply #5 –
Hi

I have the same problem with my v2a.

Yellow led and errors like these when programming with the python shell:
Verification failed at 0x00000000: 0 != 4
Verification failed at 0x00000001: 4 != 12
...


When clicking the green button using the pic24p programmer the yellow light is off, but when i unplug it and plug it on again, the yellow ligth is back.
I also updated my v2go but without any troubles.

Update:
My v2a is now alive again, with the 2.8 software.
It seems the newest v3.6 or 3.5 do not work with the v2a buspirate.

Cheers
Rubi

Re: problems loading BP3 firmware 3

Reply #6 –
@rubi - I'm glad you got it working. I didn't know anyone was using the v2a so I stopped making new compiles for it. If you like, I'll compile it for you and upload to the SVN nightly folder.
Got a question? Please ask in the forum for the fastest answers.

Re: problems loading BP3 firmware 3

Reply #7 –
Hi Ian

Please that would be great!

I like the v2a because it can use its own power supply.
Sometimes I have a short circuit on a quick and dirty test board and that would lead to a pc reboot if I use usb as power supply.

Cheers
Rubi

Re: problems loading BP3 firmware 3

Reply #8 –
Interesting.  The USB controller on the PC side is supposed to prevent this very thing from happening.  It's also supposed to know that if it can't provide 500mA when you ask for it, then it shouldn't try to honor the request.

Re: problems loading BP3 firmware 3

Reply #9 –
That's what I thought too. Nate at SparkFun and I had a conversation about this a while ago. He said he was really impressed by the resilience of USB ports in terms of shorts. I have killed exactly one USB controller, by a comedy of errors involving a (failed) Nixie tube Sudoku project.
Got a question? Please ask in the forum for the fastest answers.

Re: problems loading BP3 firmware 3

Reply #10 –
Sorry, I forgot the link to the new compile:
http://code.google.com/p/the-bus-pirate ... htly/BPv2a

This v3.6 should work for v2a.
Got a question? Please ask in the forum for the fastest answers.

Re: problems loading BP3 firmware 3

Reply #11 –
Hi

Thank you Ian!

[quote author="ericwertz"]
Interesting.  The USB controller on the PC side is supposed to prevent this very thing from happening.  It's also supposed to know that if it can't provide 500mA when you ask for it, then it shouldn't try to honor the request.
[/quote]

You can try this very easy, just short the 5V Pin of any  Usb Port against the chassy of your pc and you will notice an immeadeate reboot. I have lost quite some code this way.

My kill stats:
1 parallel port (this did really hurt)
1 usb hub
1 usb port

For about 10 years of hardware hacking not soo bad.

[quote author="ian"]
That's what I thought too. Nate at SparkFun and I had a conversation about this a while ago. He said he was really impressed by the resilience of USB ports in terms of shorts. [/quote]
Imho the most impressing port was the RS232 port, unbelievable how much abuse they could stand. :)

Re: problems loading BP3 firmware 3

Reply #12 –
USB ports generally have self resetting Polyfuse devices in series with the supply output so they're really quite hardy.

Serial ports - I've replaced many a MAX232 serial driver chip.

Cheers
Robin