next topic »

[on:]

Hi Guys, First post so be gentle!

I have a USB powered Arduino Mega 1280, which I tend to monitor using Cutecom instead of using the serial monitor, however whenever I unplug the USB and replug it in, the arduino sends null caracters (\0x00), rather than the data it is meant to. This is fixed if I open up the serial monitor, which I think must be restarting the arduino.

Why does the arduino not work immediately on power up? Even pressing the reset button on the arduino doesn't seem to solve the problem.

Baud rates are matching, 8n1 config.

I haven't bothered posting my program as it happens with any program, regardless of peripheral devices attached.

[Reply #1 on:]

Why does the arduino not work immediately on power up? Even pressing the reset button on the arduino doesn't seem to solve the problem.

Baud rates are matching, 8n1 config.

I haven't bothered posting my program as it happens with any program, regardless of peripheral devices attached.

That should be an indication that the Arduino is working.

This is fixed if I open up the serial monitor, which I think must be restarting the arduino.

It does reset the Arduino AND set some parameters for the serial port.

I have a USB powered Arduino Mega 1280, which I tend to monitor using Cutecom instead of using the serial monitor

So, the problem is not with the Arduino. It is with Cutecom.

[Reply #2 on:]

I'm having a similar problem with a couple of sketches. If I unplug the USB cable and then plug it back in, neither sketch starts up. I'm trying to sort out what's causing this.
So far, I've started from scratch with the blink sketch which restarts properly when USB is unplugged and plugged back in. I added a Serial.begin(9600) and it still boots OK.
As clong says, pressing the reboot button doesn't fix things once a sketch is hung up. You have to reload the code from the IDE.

Pete

[Reply #3 on:]

Paul, what serial settings does starting serial monitor reset? My cutecom connection is nothing fancy, I see no reason why it shouldn't work. In fact I have the same issue if I leave serial monitor open. Only fixes the problem when it restarts the board.

Pete, that's interesting, I'll put the blink sketch on and see if I get the same result. How do you know the program is in a hung state? My board still sends null bytes when I would be expecting normal characters (every 10 seconds), so I don't think it can be hung. I might stick some led bits in to see..

[Reply #4 on:]

The conditions I'm experiencing are similar to what this guy writes about: http://arduino.cc/forum/index.php?topic=23025.0;wap2

I have noticed something else; adding a blink, the blink works correctly on start up every time. But the Tx LED doesn't flash when it should- regardless of hardware restart. This shows that the program is running fine, but unable to transmit data via USB.

This suggests that the FTDI serial adaptor isn't able to communicate with the chip on start up.

Surely this issue has been documented somewhere else? Anybody come across this problem before?

[Reply #5 on:]

That does seem like some of the problem I've been having on the Nano. But I also have a Duemilanove and that also exhibits this kind of problem.
I'm still trying to nail this down to something repeatable in a small amount of code.

[edit] @clong - thanks for that link.

Pete

[Reply #6 on:]

I have just noticed, when working correctly, the Tx LED flashes once every 10 seconds.

When the unit is powered up via USB, however the LED on pin 13 continues to flash even though the Tx LED doesn't flash. This only fixed by opening up serial monitor.

Surely this proves the that the problem resides in the initialisation of serial communication on the arduino? I tried sticking a few delays in the program setup but it doesn't seem to have helped.

Is there any other way I can manually force the serial connection to be reset from the arduino side?

[Reply #7 on:]

Okay I think I figured this out- turning on hardware handshaking in my terminal client seems to solve the problem!

Hope it sorts you out Pete.

[Reply #8 on:]

Okay I think I figured this out- turning on hardware handshaking in my terminal client seems to solve the problem!

Great news. Thanks for the follow up. This issue seems to cause a lot of people grief, so having at least a possible suggestion to offer will be helpful.

The frustrating thing is that each application uses different names to enable/disable whatever this particular feature name is enabling/disabling. It's better than nothing, though.