what's the matter with the UNO's Atmega16u2

When I open the serial port, the led (indicates the data stream is from USB to UART) is always off, but the Atmega16u2's Tx pin pulled down two times. I think it is a bug,

Why do you think it's a bug? When you open Serial monitor the Arduino is reset :slight_smile:

septillion:
Why do you think it's a bug? When you open Serial monitor the Arduino is reset :slight_smile:

even if reset the mcu, all the GPIOs are floating

gicren:
even if reset the mcu, all the GPIOs are floating

You're not giving very much to go on. Which board? When you say "open the serial port", do you mean open the serial monitor, or when you read/write the serial port in your code?

Can you upload code to the chip? Does your code work?
Can you print to the serial monitor?
Can you receive from the serial monitor?

The pins default to input on startup, unless you set them up otherwise, so they will be floating.

More information please. Be specific.

OldSteve:
You’re not giving very much to go on. Which board? When you say “open the serial port”, do you mean open the serial monitor, or when you read/write the serial port in your code?

Can you upload code to the chip? Does your code work?
Can you print to the serial monitor?
Can you receive from the serial monitor?

The pins default to input on startup, unless you set them up otherwise, so they will be floating.

More information please. Be specific.

  1. UNO, board is ok, no other problems.
  2. “open the serial port”, just open the serial port on monitor. I have had many tests on different serial monitors. If you want to test with the serial monitor which integrated in the Arduino IDE, please set the baudrate to 115200bps, the problem will appear.

I'm happily using 115200 without issues on Uno and Redboard.

sterretje:
I'm happily using 115200 without issues on Uno and Redboard.

How do you test it? Do you use the oscilloscope to test the Atmega16u2's Tx pin or the Atmega328's Rx pin when you open the serial monitor?

baudrate is irrelevant to the issue

I was not going to look for this… but then I did. I see a 40uSec glitch on the mega328p Rx pin when I open a terminal…

O-scope_plot_at_terminal_open.png

O-scope_on_RX(ISPtool).png

TerminalUsed.png

Since I don’t use the Atmega16u2 for any of my projects, I think I will spend the rest of my time happily ignoring this.

gicren:
baudrate is irrelevant to the issue

Then why did you say this:- "please set the baudrate to 115200bps, the problem will appear."

There is no issue. If everything is working OK, what makes you think there's some kind of bug?
As septillion said in the first reply, the Arduino is reset when you open the Arduino serial monitor. That's by design, not a bug.

You're just wasting people's time here.

gicren:
How do you test it? Do you use the oscilloscope to test the Atmega16u2's Tx pin or the Atmega328's Rx pin when you open the serial monitor?

Just communicate.

gicren:
baudrate is irrelevant to the issue

So why did you post the below?

gicren:
If you want to test with the serial monitor which integrated in the Arduino IDE, please set the baudrate to 115200bps, the problem will appear.

I see a 40uSec glitch on the mega328p Rx pin when I open a terminal.

40us is a good several bit times at 115200bps; sounds like it could be a real bug to me. (it SHOULD show up as a spurious character being received by the Uno sketch, too. Does it?)

westfw:
40us is a good several bit times at 115200bps; sounds like it could be a real bug to me. (it SHOULD show up as a spurious character being received by the Uno sketch, too. Does it?)

But won't the chip reset when opening the serial monitor cause the pin to float for a moment?

Edit: No matter how many times I open the serial monitor, I don't get a spurious character when I open the serial monitor. I tried with this:-

void setup()
{
    Serial.begin(115200);
    if(Serial.available()>0)
    {
        Serial.println("Got something");
    }
}

void loop(){}

I reckon the pin glitch only happens during the reset period, so nothing appears in the serial RX buffer.

Is my test flawed?

Latest test report

  1. Low level width is not always 40us.
  2. High level width varies with the baudrate without any rules.
  3. It is not fixed when open the serial monitor with the same baudrate.

OldSteve:
But won’t the chip reset when opening the serial monitor cause the pin to float for a moment?

Edit: No matter how many times I open the serial monitor, I don’t get a spurious character when I open the serial monitor. I tried with this:-

void setup()

{
   Serial.begin(115200);
   if(Serial.available()>0)
   {
       Serial.println(“Got something”);
   }
}

void loop(){}




I reckon the pin glitch only happens *during* the reset period, so nothing appears in the serial RX buffer.

Is my test flawed?

you can’t get the issue via code

P60908-153151.jpg

gicren:
you can't get the issue via code

If it doesn't affect code, is it really a concern? It appears that it only happens while the '328P chip is still in reset, so there should be no problem. The '328P isn't running code at that stage.
I think you're over-analysing things. If there's no problem when running code, why worry about it unnecessarily?

But won't the chip reset when opening the serial monitor cause the pin to float for a moment?

It shouldn't. The 16u2 resets the 328, but the 16u2 itself shouldn't reset, and should continue to drive the TX pin high.
(also, those scope photos show a much clearer blip than you'd get if the chip went floating.)
There code in the usbserial firmware that says:

/* Must turn off USART before reconfiguring it, otherwise incorrect operation may occur */

Perhaps when the USART is turned off, the GPIO hardware regains control of the pins and defaults them to "zero" instead of the "one" idle state ? (Hmm. Confirmed that LUFA messes with DDRD3, but not PORTD3. Buy I'm not sure why the timing would be inconsistent.)

westfw:
It shouldn't. The 16u2 resets the 328, but the 16u2 itself shouldn't reset, and should continue to drive the TX pin high.
(also, those scope photos show a much clearer blip than you'd get if the chip went floating.)

Yeah, I realised that after I posted. A moment of confusion. :slight_smile:

Perhaps when the USART is turned off, the GPIO hardware regains control of the pins and defaults them to "zero" instead of the "one" idle state ? (Hmm. Confirmed that LUFA messes with DDRD3, but not PORTD3. Buy I'm not sure why the timing would be inconsistent.)

Yes, you'd expect exactly the same timing every time. Aside from that, I'd say you're probably right about the pin going low while the USART is reset.

Still, I don't think it's a real problem or "bug", assuming it always happens while the '328P is still in reset. I'd only be concerned if it happened after reset was released. After all, everything works fine in operation.

OldSteve:
If it doesn’t affect code, is it really a concern? It appears that it only happens while the '328P chip is still in reset, so there should be no problem. The '328P isn’t running code at that stage.
I think you’re over-analysing things. If there’s no problem when running code, why worry about it unnecessarily?

But, it is very unfavorable to the module which directly connected to the Atmega16u2.

I want to emphasize that it is pull-down not floating