Go Down

Topic: Arduino DUE cannot receive serial input on D0/RX0? (Read 2437 times) previous topic - next topic

bentonite

I am trying to confirm that digital pin 0 (RX0) does not work to receive TTL serial data.

I can successfully receive serial data on RX1, RX2, and RX3. I can also successfully send data on TX0. I am using an FTDI TTL-to-USB cable.

Neither DUE USB ports are in use or connected.

As far as I can tell there is no difference in the method I use to connect to any of the serial ports.

I don't have an oscilloscope but as far as I can tell (using a multimeter) RX0 behaves differently from RX1, 2, or 3. Whereas I can see voltage changes on the latter three pins when receiving serial data, pin 0 (RX0) holds a very steady 3.3V at all times.

I have observed this behavior on 2 separate DUEs. It seems so odd that I think I must be overlooking something obvious.

Has anyone successfully used RX0 to receive data?


MorganS

Has anyone successfully used RX0 to receive data?
Yes. All the time.

As far as I can tell there is no difference in the method I use to connect to any of the serial ports.
As far as we can tell you haven't posted any code to support this assertion.
"The problem is in the code you didn't post."

bentonite

@MorganS, thanks for the answer.


Quote
Yes. All the time.
Good to know. But frustrating.

Here is a test sketch that I am using:

Code: [Select]



#define BAUD_RATE  38400

void setup() {
 
    /*
     * initialize serial communication on all portd
     */
    Serial.begin(BAUD_RATE);
    Serial1.begin(BAUD_RATE);
    Serial2.begin(BAUD_RATE);
    Serial3.begin(BAUD_RATE);
}


void loop() {
 
   
    //Serial.println("=TX0="); // uncomment to test if the TX line is working regardless of input
    if (Serial.available()) {
        Serial.write(Serial.read());
        Serial.print(0);  // intersperse chars with a marker
    }
   
    //Serial1.println("=TX1="); // uncomment to test if the TX line is working regardless of input
    if (Serial1.available()) {
        Serial1.write(Serial1.read());
        Serial1.print(1);  // intersperse chars with a marker
    }
   
    //Serial2.println("=TX2="); // uncomment to test if the TX line is working regardless of input
    if (Serial2.available()) {
        Serial2.write(Serial2.read());
        Serial2.print(2);  // intersperse chars with a marker
    }
   
    //Serial3.println("=TX3="); // uncomment to test if the TX line is working regardless of input
    if (Serial3.available()) {
        Serial3.write(Serial3.read());
        Serial3.print(3);  // intersperse chars with a marker
    }

}


The intent of this code is to echo back any received data on the same port it was received (along with a marker char to verify the origin).

I am using a simple PC based program to send the string "ABC" once per second and to output any received chars.

I am using an FTDI USB-TTL cable to connect to the DUE with three wires.
GND - GND
TX - RX (on port being tested)
RX - TX (on port being tested)

I am moving the TX and RX lines to each of the serial port pair in sequence and monitoring the output (if any).

Attached you will see a picture of my setup with the TX/RX lines attached to RX0/TX0.

This works perfectly for Serial1 (RX1/TX1), Serial2 (RX2/TX2), & Serial3 (RX3/TX3) but not for Serial (ie., pins RX0/TX0).

Uncommenting the line //Serial.println("=TX0=");
results in the "=TX0=" chars being received at the PC (assuming the FTDI cable is attached to RX0/TX0).

I have subsequently also tried this on a 3rd DUE straight out of the box with the same results.

There is some chatter on the internet regarding this issue but nothing I can see as definitive.

Some peoples issues appear to revolve around trying to use the USB programming port at the same time as RX0. This is not the case in my setup.

Other people have suggested applying either a pullup resistor or a pulldown resistor to the RX0 port. I have not tried a pullup resistor because my RX0 pin never seem to go low at all. I have tried various pulldown resistors with no effect.

http://forum.arduino.cc/index.php?topic=257266.0
https://forum.arduino.cc/index.php?topic=384111.0
https://github.com/arduino/ArduinoCore-samd/issues/48


thanks for your input!

bentonite

Attachment failed :( Attempt 2.

ard_newbie

#4
Feb 05, 2017, 06:45 am Last Edit: Feb 05, 2017, 09:41 am by ard_newbie
AFAICT rx0 and tx0 is the "echo" of the communication between arduino due and atmega16u2.

What happens if you try this :


Code: [Select]

void setup()
{
    Serial.begin(115200);
    Serial1.begin(115200);
}

void loop()
{
    if (Serial1.available())
        Serial.write(Serial1.read());

    if (Serial.available())
        Serial1.write(Serial.read());

    delay(1000);
}


And FYI, there is a Serial4 available if you need 5 U(S)ART(s).

See this thread, reply #3 :

https://forum.arduino.cc/index.php?topic=384111.0

weird_dave

#5
Feb 05, 2017, 08:46 am Last Edit: Feb 05, 2017, 09:02 am by weird_dave
Does it work if you use the serial monitor in the IDE? (without the FTDI cable attached)

Edit:
I've gone over the circuit diagram of the Due a few times and I do think this should work, but, it's not the best port to use as the RX pin could be forced low by IC6 (the AT16U2, IC10 ensures the RX pin is either 3-state or low)

bentonite

@ard_newbie: I will try your code as soon as I can. Thanks for the tip on the 5th port. In my application I need 5 ports. My design uses the 4 hardware ports and one software serial port. Had I known about the  5th port when I was designing my boards I probably would have used it in preference to creating a software port. As I don't need duplex comms in all cases I have been able to use the RX line of another port to work around the RX0 problem. This is really more of an abstract question to try and understand what I am seeing and perhaps to do things differently in future if needed.

@weird_dave: yes, there is no problem with two way communications using 'Serial.xxxx'  commands if I use a usb cable plugged in to the programming port. 

MorganS

And FYI, there is a Serial4 available if you need 5 U(S)ART(s).
Where? Not in my version of the DUE variant.h.
Code: [Select]
Arduino: 1.6.13 (Windows 10), TD: 1.35, Board: "Arduino Due (Native USB Port)"

C:\Users\username\AppData\Local\Temp\arduino_modified_sketch_834122\sketch_feb05a.ino: In function 'void setup()':

sketch_feb05a:3: error: 'Serial4' was not declared in this scope

   Serial4.begin(9600);

   ^

exit status 1
'Serial4' was not declared in this scope

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.


The USB serial can be used as a 5th serial, if the only purpose is to communicate with a PC via USB. It's not a USART.
"The problem is in the code you didn't post."

bentonite

Where? Not in my version of the DUE variant.h.
I think ard_newbie was referring to the one described in this post:
https://forum.arduino.cc/index.php?topic=384111.msg2649618#msg2649618

Quote
If you need an additional Serial port on the Due, there's one on pins A11 (TX4) and D52 (RX4) that uses USART2 and can be assigned as Serial4.

MarkNowell

Apologies in advance for whatever crimes I'm committing by updating this thread, but if this is where you find yourself when searching for Due RX0 then hopefully this will help...

Short answer - if you need to use the RX0/TX0 port direct to the SAM3X you can by removing IC10. This will disable programming via the 16U2 USB programming port however you can still program via the native USB port (I've seen suggestions this doesn't always work but it does in my limited experience).

Longer version - I want to be able to flash the SAM3X from a linux device without using USB and I believe the TX0/RX0 port allows use of the SAM3X rom bootloader via TTL serial. In common with others I have found that RX0 is constantly driven by the 16U2 via IC10. The reference Due schematic suggests that IC10 is intended to tri-state the 16U2 tx line but it appears most/all Due boards have IC10 ~OE tied to 0V so IC10 is just used as an unnecessary buffer.

There's a good picture showing the actual location of IC10 in this thread (covering differences between Due reference design and actual boards):

http://forum.arduino.cc/index.php?topic=168399.0


Go Up