USB BUB I upload problem

[grovesr]

Hi,
I am trying to use the USB BUB (v1.0) to upload an Arduino 1.0 IDE sketch to a breadboarded Atmega328p with the optiboot bootloader (purchased from Modern Device). I am using instructions for breadboarding the Atmega from http://itp.nyu.edu/physcomp/Tutorials/ArduinoBreadboard.

I am getting the following error in the Arduino IDE after attempting an upload:

Code: Select all

avrdude: stk500_getsync(): not in sync: resp=0x00

I have gone through this topic thoroughly on the forum as well as checking out all the FAQ suggestions at the top.

On the BUB I have jumpered the 5V logic level connection and am using the 5V supply from the BUB to power the breadboard.
The BUB is recognized by my laptop (windows XP) and I see the communication LED blink whenever I connect the USB cable. I have downloaded the latest drivers and installed them several times (have tried both 2.08.14 and 2.08.17beta versions of the driver). I have also checked for shorts that I might have created when I soldered on the headers and all looks good there.

The Atmega operates fine. The reset button on the breadboard successfully resets the chip and pin 13 blinks an LED (reset pullup is 8.6 kOhms). I can upload new programs to the Atmega flash memory using an AVR ISP MKII and the ICP connections, so the Atmega seems to be working just fine.

I have scoped the RST, TX, and RX lines at the Atmega and see the following during an upload attempt:

• 1) all three lines are at 5V initially
  2) RST goes low one or more times, it is difficult to tell how many times since I don't have a storage scope
  3) RX (Atmega pin 2) goes low several times
  4) TX (Atmega pin 3) has some noise on it, but it never goes low enough to trigger the scope (negative slope trigger)
  5) after upload attempt all three lines return to 5V and stay there
  6) no blinking on the BUB RX/TX LED at any time during upload

I'm kind of out of ideas to check at this point? Am I doing something wrong? Is the BUB defective? Oh yeah, I have never used the BUB successfully.

[grovesr]

Figured it out. The Atmega328P is defective. I had a 168 sitting around and replaced the the 328 with the 168 in the breadboard and now it works perfectly.

[grovesr]

Final update. Just discovered that I accidentally erased the bootloader when programming via the ICSP using the AVRISPMKII. I discovered this by suddenly being unable to use the USB BUB with another 328p from the Arduino IDE.

For you folks out there that are not aware: In Atmel Studio 5, when programming, make sure not to check the "erase device before programming" selection in the programming interface. That erases the bootloader too!

[egroeg1]

I have been using pre-optiboot versions of RBBB and BBB (both ATmega328P) with USB-BUB (v1).
These have been working well together.
More recently, I tried to flash the new optiboot bootloader for slightly more code space.
After doing so, I encounter pretty much exactly the same exhibited diagnostics and symptoms described here.
I remembered to switch selection of board to "Arduino Duo", so that is not the issue.
Nonetheless I was NOT able to upload sketches from Arduino IDE v1.0.3 at all.

I reverted and reflashed with the original Duemilanove w/ 328 bootloader,
and then I was able to upload sketches again. Hardware setup was unchanged.

I found my results to be consistent across both 328P chips and boards.
grovesr declared that his ATmega328p chip was bad.
But it's clear mine are fine if I revert back to the old bootloader. So I wonder...
Are there timing/voltage issues with the USB-BUB (v1) when used with new optiboot
that might be causing these program upload failures?

[paul]

The Arduino setting you want with Optiboot is "Uno" not "Duo" but I suspect it's just a typo. If you were using Arduino "Due" you would have had no success since that is an Arm chip.

I can't explain what's going on. We have sold multiple 1000's of RBBB and BBBB with Optiboot and it works flawlessly (as much as any Arduino bootloader works flawlessly). In any of the chips for example, you can still create situations where if you send serial back to the laptop fast enough, you will disable automatic upload, and you will have to push the reset button at the correct moment to get the board to upload.

Paul

[egroeg1]

Hi Paul, (It was a pleasure to meet and talk with you last May at Maker's Faire)

Thanks for responding.
Sorry for any confusion. Yes, I meant to type "UNO", not "Duo"

Lucky timing: I was working to debug a student's non-functional RBBB and BUB-II last night and may have cracked the mystery.

For our course, we purchased an additional batch set of ~10 RBBB/BUB-II in December, so these are ones with Optiboot. The particular setup these students having problems with exhibited the same upload problem. However, when swapping in other BUB-IIs to diagnose which part was suspect, the uploads were fine with the other BUB-IIs. What was strange was that if I hooked up this suspect BUB-II to one of my old RBBBs (w/ non-Optiboot), this BUB-II would work fine. So the story is beginning to sound similar....

Examining this suspect BUB-II, I noticed that the student had soldered up the BUB-II with jumper headers for both LGLV and VOUT, and inserted shorting headers. I carefully traced the board connections with a meter and double checked against the schematic. It turned out the students did such a bad job soldering (big round balls of solder at the header pin connections), they had overheated, and broke a couple of the pads/traces at the header pin through holes. The pads are small and were invisible having become engulfed inside solder balls. Summarizing, the pad for 3_3Vout on LGLV selection had become disconnected, as well as the 3V option on the same header block.

With this discovery, further reviewing the schematic and digging around some more on your website, I noticed a note on one particular page for the old BUB-I mentioning something about a line that should not be left floating for Optiboot, but is OK to leave floating for Duemilanove. After reading that over a few more times, I went back to my old BUB-I, added the respective LGLV selection jumper. AND THEN... hey what do you know, uploads to Optiboot works now! Hurray! So I believe I've solved my mystery.

Figuring I now had the answer, I went back to the suspect student's BUB-II. I patched the damaged PCB, and verified those connections were now good. Sadly, this BUB-II still doesn't work correctly with Optiboot, only with the old bootloader.
It is possible the students damaged the FTDI chip --> they didn't remove the on-board default soldered connections for LGLV and Vcc selections. When trying varied combinations of the shorting jumpers to see if they could make things work, it's not certain what voltage combinations were fed to the various pins on the FTDI chip.

[paul]

It's slightly weird that it works with older bootloader but not the new one. The upload speed and timing are different on Optiboot which probably makes the floating logic line issue problematic. I'd say confirm that the logic line pin is not floating on the BUBII and that the headers are soldered on decently. After that, if it still doesn't work, my advice would be to give up on the (tortured) board and we'll send you a new one. Just email off the forum and we'll fix you up as a reward for your diligent troubleshooting

Paul