Go Down

Topic: [SOLVED] RX pin doesn't work (Read 830 times) previous topic - next topic

SilverGreen93

May 02, 2017, 08:43 am Last Edit: May 27, 2017, 08:46 pm by SilverGreen93
Hi,

As I read elsewhere on this forum or maybe on some other forums, it seems that the RX pin for Serial0 cannot be used because it is used by the ATmega for the USB-to-serial adapter. So I thought why would it work for the Uno and Mega, but not for the Due.

I first checked the difference in the schematics. As one can see (mega.png), for the Mega, the RX and TX pins are connected directly (through resistors) to the main chip, but for the Due (due.png) a Bus-line driver is used to control the RX line and no resistors are used. As I can understand this is necessary because the Dues uses 3.3V and the Atmega 5V, so this acts as a level translator.

Now, looking at the truth table of how a bus driver works (table.png), it seems that the High-Z state is obtained when #OE is HIGH. Because in the schematic the Input and #OE are tied together, one can deduce that the output can be either LOW or High-Z, but never HIGH.

So I used an oscilloscope to see myself if that is true, but surprisingly, when idle, the line is held HIGH. When I tried to connect a TX signal from my PC to the RX line, the line stays always HIGH as if it is directly connected to 3.3V.

My questions are:
1) How that the line can be HIGH and not High-Z? Why is the line held HIGH and cannot be used for external communication?
2) Can I fix it by adding a resistor somewhere in between the output of the buffer and the RX pin of the main chip? I think I can cut the trace and add a resistor here (resistor.png)

Hope we can get to the bottom of this!

PS: I know I can use other serials and don't bother with this, but I have a specific application that needs Serial0 and It is weird why it wouldn't work.

ard_newbie


If you look at the PIO section of the datasheet page 654, you will see that a PIO line can be pulled_up by:

PIOx->PIO_PUER |= PIO_PUER_Py;  // Where x is A,B,C or D and 0<= y <=31

alternately a pull_up can be disabled by:

PIOx->PIO_PUDR |= PIO_PUDR_Py;

I guess that during UART initialization, PA8 and PA9 are both pulled_up.


SilverGreen93

#2
May 02, 2017, 12:05 pm Last Edit: May 02, 2017, 12:13 pm by SilverGreen93
Ok, but an internal pull up resistor is fine, it should have allowed me to communicate properly.
Can I disable the pull_up directly in arduino sketch by using the command you supplied and test? Is there any downside to disable it? (Maybe loose communication with Due)

MorganS

Of course it can be used. Have you tried it? I have a dozen Due's happily receiving data on Serial with no problems.
"The problem is in the code you didn't post."

SilverGreen93

#4
May 02, 2017, 09:37 pm Last Edit: May 03, 2017, 09:48 am by SilverGreen93
Of course it can be used. Have you tried it? I have a dozen Due's happily receiving data on Serial with no problems.
Of course I tried it. :) I even used an oscilloscope to prove to myself that it doesn't work. It only works with the onboard USB interface.
What is your setup? How did you get it to work?

There are others who have reported the same: http://forum.arduino.cc/index.php?topic=257266.0

bobcousins

I looked into this a while back, a post about is http://forums.reprap.org/read.php?13,287434 The Due design has had a few changes, but I don't think a change log is publicly available.

The old Due design had #OE connected to ground, so that the driver is always enabled. The idle state of a UART is High. As you found, this can prevent re-use of Serial0.

At some point the Due design was changed to wire #OE to it's input pin, so that it is only driven low. With the Atmega UART in the idle state, the '125 buffer chip is High-Z, allowing re-use of Serial0.

Because Arduino don't label versions, and anyway don't have control of clone makers, the only way to find which version of Due you have is to examine it under a microscope. I'll bet you have the earlier version where #OE is connected to ground.

I actually had the opposite problem, with '125 buffer in a High-Z state, there is only a weak pullup on the RX line, so higher baud rates didn't work reliably.
Please ask questions in the forum so everyone can benefit. PM me for paid work.

SilverGreen93

Thanks for the info! I'll look into it, maybe you're right. On a first glance I already can see that the T3 transistor is in another position (90* rotated) that in the PCB design files. Maybe the buffer is held #OE low. I haven't checked, relied only on the schematics.

SilverGreen93

#7
May 04, 2017, 08:17 am Last Edit: May 04, 2017, 10:02 am by SilverGreen93
Oh rats! It seems that, @bobcousins, you are right! I do have the initial revision of the board where the T3 transistor is horizontally and I need to add the resistor in between its legs for "load on reset" fix.

I measured and it's true that the #OE line of the buffer is grounded...
What is your suggestion? Should I desolder the tiny line buffer, cut the ground plane/trace, and make a solder blob between #OE and Input? Or is it easier to cut the output trace as I indicated in my screenshot and add a 1K resistor between the buffer output and the RX input pin of the chip? (Presumably both solutions will work the same)

Thanks!

PS: Arduino should have noted revision changes between boards...

weird_dave

It's bloody annoying, I have both types sat here, my ebay knockoff which doesn't have the arduino logo or wording looks like the one on the Arduino Due web page, my more recent purchase of 'proper' ones look different. Both have R3 written on them, how helpful!

bobcousins

What is your suggestion? Should I desolder the tiny line buffer, cut the ground plane/trace, and make a solder blob between #OE and Input? Or is it easier to cut the output trace as I indicated in my screenshot and add a 1K resistor between the buffer output and the RX input pin of the chip? (Presumably both solutions will work the same)
That's a good question. The first replicates the latest Due schematic, so would be the "safe" choice. Those little chips are quite fragile though, I destroyed one in my first attempt at rework. Adding the resistor on the output might be easier and I think is a better solution. I would probably use 4k7 there.

I noticed a few little changes on the Due schematic, there is the T3 mod, plus R23 changed to 1k. D1 has been removed, and D5 added in a different place around the DC jack, X2. (Reverse polarity protection I think). There are other changes on the layout, e.g. IC10 is in a completely different place.

At work, we have to deal with a lot of engineering change control, it seems tedious but turns out to be quite useful!
Please ask questions in the forum so everyone can benefit. PM me for paid work.

SilverGreen93

The first replicates the latest Due schematic, so would be the "safe" choice. Those little chips are quite fragile though, I destroyed one in my first attempt at rework.
I thought that it would be very hard to remove and resolder the tiny buffer, letalone that the GND is a plane and NOT a trace, it will be harder to cut loose.
I will order some 0603 resistors and will try the fix by cutting the output trace and soldering there. I will also modify R99 and maybe R23 if I get into problems with reset.

SilverGreen93

I just received my set of 0603 resistors and I was able to mod my Due to get both the reset problem fixed and the RX pin working!

For the reset bug I used a 10k resistor soldered between the pins of the transistor.
For the serial RX bug I cut the trace that went from the output of the buffer to the closest via and added a 5k1 resistor soldered one end on the pin and the other end on the via after I scraped the solder mask off.



Hope this can help others with the same problem that have the same Arduino Due revision that has the /OE and GND pins of the buffer tied together.

Now all works fine. I have tested with an external TTL Serial to USB adapter. :)

Go Up