Using Serial.print bricks Uno board ?

[andesite]

Using Serial.print bricks Uno board ?

Received an Uno board today.  (Never worked with Arduino before, however have worked with the 168 and 328 chips previously in other environments.)

Wrote a simple program using the IDE.  Host system is Linux (Linux Basalt 2.6.35.10-74.fc14.i686.PAE)

Using Serial.print appears to brick the Uno.  
The problem is described in detail in the following posts (I won't repeat the details here, my problem is exactly the same as described in these posts).

num=1286088093/0
num=1286350399

Sorry - no links, forum won't allow me to upload them.

At this point the Uno appears useless, before I toss it in the trash can anyone with experience on the Uno board help the the following questions?

1. Confirm that using Serial.print in a program bricks the Uno.  That is, serial communication between the Uno and computer  using USB cannot be used, and the serial monitor in the IDE cannot be used.  (or any other serial monitor such as minicom.)

2. Is there any method to 'unbrick' the Uno?  

3. Is there any method to make Serial.print work on the Uno (assuming it can be unbricked)?

If using Serial.print bricks the Uno this is a catastrophic limitation of the Uno and renders it useless for development.

[PaulS]

Serial.print by itself does not brick the Uno. Serial.print so often that the Arduino doesn't have time to do anything else can.

There is a fix for the problem, posted in one of the threads that talks about the problem. I don't have a Uno, or the problem, so I don't have the thread bookmarked.

Serial.print() with delays between the prints also solves the problem.

Yes, the Arduino can be unbricked. It takes some patience to get the timing of the reset right, as I recall.

[retrolefty]

Don't own a Uno, but do recall reading here that there is a problem if a prior loaded sketch starts right off blasting serial characters following a reset (either power up or via auto-reset preamble to uploading) the 8U2 chip (emulating a usb serial converter) doesn't initialize correctly and gets kind of locked up preventing any further downloads from working. If a sketch starts off with a small delay before performing serial outputs that seems to be a temp fix, but doesn't solve your existing sketch. There does seem to be a bug fix entry (http://code.google.com/p/arduino/issues/detail?id=405&q=uno) so maybe a fix in coming soon?

I guess you should just check here to see if anyone found a way out of your existing situation.

Lefty

[pluggy]

You need to update the 8U2 firmware.

Post #34 in this thread :  http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1286088093/30#30

[andesite]

Thanks for the replies and information.
Problem solved, thanks for the help.

In case others have the same problem here is how I resolved this:

To un-brick the board I downloaded a very simple program (blink an LED).  To get this to work I plugged in the USB cable while holding down the reset button, start the upload to the board (from the IDE) and simultaneously release the rest button.  This took a few attempts to get timing right, it did work after a couple of tries.  The point is to start the upload before the serial communications from the board starts.  

Once the board was 'un-bricked' I update the 8U2 firmware as described in reply #3 above.  
This worked on the first attempt, no problems at all.

With the firmware update complete everything works fine, no problems.  Created a couple of programs that used the serial monitor.  All worked with no issues.  

Thanks!

[liudr]

Man, that sucks. I'm super glad that I have purchased one of the last dozens of Duemilanoves.

Here is my take: if the Atmega bricks the 8u2, can I remove the Atmega and then update the 8u2, then put the Atmega back in? Will this solve the problem?

[retrolefty]

Here is my take: if the Atmega bricks the 8u2, can I remove the Atmega and then update the 8u2, then put the Atmega back in? Will this solve the problem?

That sounds very cleaver to me, however I don't own a Uno.

[James C4S]

Here is my take: if the Atmega bricks the 8u2, can I remove the Atmega and then update the 8u2, then put the Atmega back in?

It seems reasonable.  The 8u2 shouldn't need to communicate with the ATmega in order to be reprogrammed...

[liudr]

Can someone with a bricked UNO test out this wmethod and confirm? I think this is like a sure way to do it, if it works. Beats sweaty hands on the reset button.

[retrolefty]

Beats sweaty hands on the reset button.

Maybe, for some. I've seen people destroy dip socketed ICs trying to remove them from their sockets. But I do think it would work (pulling the avr) and it would nice to have two proven procedures, one that doesn't require experience with carefully removing ICs. Having a choice is always nice.  

PS: If defeating the running AVR is the key to reloading the firmware on the 8u2, wouldn't simply wiring a jumper between ground and the shield reset pin allow the firmware procedure to continue?

Lefty

[stimmer]

As far as I remember, the 8u2 firmware update procedure will still work even if the Uno is in a 'bricked' state, so you shouldn't need to remove the 328 to update the 8u2 firmware. As soon as the 8u2 is put into DFU mode it ignores the serial connection from the 328 anyway.

So it should just work whether you remove the 328 or not.

[James C4S]

If defeating the running AVR is the key to reloading the firmware on the 8u2, wouldn't simply wiring a jumper between ground and the shield reset pin allow the firmware procedure to continue?

Is holding the micro in reset a software or hardware solution?