Arduino failing loopback test despite working perfectly otherwise

AleksandurMurfitt · August 1, 2017, 9:01pm

I tried a loopback test yesterday on my (genuine) UNO, and despite having everything setup as it should be (RX connected to TX and GND to RESET) I don't get an 'echo' on my computer. I have tried two different laptops, three operating systems (Ubuntu, Windows and OSX), two USB cables and even tried replacing my UNO with a Nano!

In each of these cases, I am able to receive data over serial from the Arduino if a sketch is running, and can setup a sketch that echos all received data back as well, so there's clearly nothing wrong with the hardware. When I send data to my Arduino (in loopback mode) both TX and RX flash, so the connection between the two is fine too. If I connect my Nano's TX to my UNO's RX (or vice versa) when my UNO has its RESET grounded, any data sent by my Nano reaches my computer perfectly.

I have tried every test I can think of and, so far, every one of them has indicated that my Arduino(s) are perfectly fine. So why is my loopback test failing, when the Arduinos both work as expected when doing anything else?

kprims · August 2, 2017, 2:00pm

Too bad you used the "genuine" label. I just found out that any clone Arduino using the ch340 chip won't work on the loop back test. I tried several including a Nano. Clones using Mega16u's work fine as well as a Genuine Uno.

I hope someone will verify this to make sure I am not up in the night.

septillion · August 2, 2017, 2:09pm

@kprims, nonsense! Loopback test works on every serial communication.

AleksandurMurfitt · August 2, 2017, 2:39pm

@kprims, why would any USB-serial chip fail a loopback test? There must something wrong with the way the chip is connected or something, rather than the chip itself.

kprims · August 2, 2017, 5:11pm

"@kprims, nonsense! Loopback test works on every serial communication."

@septillion, It may be nonsense to you, but after testing 6 different Uno's with the ch340g chip I come up with that same problem.

An atmega 2560 with the same chip works fine on the loopback test.

My failures were just like Post #9.

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

IDE 1.8.3
Linux Mint 18.2

I have no problems loading sketches and using the serial port.

I tried the loopback test because of the OP and was surprised to find loopback wasn't working on smd clone uno's.

I used a USB 3 port as well as a USB 2 port and three different cables.

Used a different Linux computer and still the same result with the ch340g chip failing.

This thread seems to talk about a problem using loopback on ch340g Uno's.

https://arduino.stackexchange.com/questions/20327/arduino-uno-rx-tx-speaks-to-itsel

More information on Nano's with ch340g.

github.com/grbl/grbl

Sent lines different from GRBL echoes

opened 07:00AM - 14 Nov 15 UTC

109JB

First. let me appologize for the length of this post, but I feel this is a very …important issue. I have been doing some more testing to verify GRBL's running of g-code files. I decided to get a serial port sniffer program to see exactly what is being sent, and what is being received to verify if any of these uncovered errors are from my GUI, or something else. What I have determined is that the data sent to GRBL is correct, but the echoed return is not correct, meaning the error happens somewhere either in the arduino, or in the GRBL code. See the following description to see how I came to this conclusion. As further testing, I made a small program to use for testing. This program has streaming code that is very streamlined with nothing extra except what is absolutely necessary for streaming and for detecting GRBL error messages. Nothing else. Both the send-response and the character counting protocols can be used and both have generated errors. The only other thing the program does is record the GRBL echoes so they can be compared to the original code for discrepencies. The files can be streamed to GRBL without any timed status requests and the following errors were encountered with timed status responses turned off. I am testing with a CAM generated g-code modified to have only G0 commands. This results in very fast streaming. If I slow the stream down a little by placing an intentional delay in the streaming code, it works as expected without errors, but at full speed GRBL doesn't always echo back the same line that was sent and/or throws errors. I have verified that the lines sent are correct by using a serial port sniffer program. For example, in a recent run using the character counting streaming, the following lines were sent at the very start of the run: G01G21G90X-0.5375Y3.5375Z3.3598F4000 X3.8999Z1.0234 X3.896Z1.0262 X3.8645Z1.0475 X3.8566Z1.0527 **X3.8212Z1.0742** X3.8173Z1.0765 The above first 7 lines were immediately sent by the GUI and the character count, including a LF at the end of each line coincidentally totals 127 characters which fills the RX buffer, and the sent lines were verified using the serial port sniffer. The response from GRBL was: [echo: G01G21G90X-0.5375Y3.5375Z3.3598F4000] ok [echo: X3.8999Z1.0234] ok [echo: X3.896Z1.0262] ok [echo: X3.8645Z1.0475] ok [echo: X3.8566Z1.0527] ok **[echo: X3.8999Z1.0742]** ok [echo: X3.8173Z1.0765] ok Note the 6th line. The echo from GRBL has the wrong X value but the correct Z value. Remember that all of the above information is from a serial port sniffer and not from my own program. However, my test program shows the exact same thing when comparing the echo from GRBL to the original G-code file, showing that the 6th line does not match. A second run of the same file got through this point fine without an error. # During another test run, the lines sent were: X2.8811Z1.167 X2.889Z1.1702 X2.9362Z1.1889 X2.9441Z1.192 with these responses from GRBL [echo: X2.8811Z1.167] ok [echo: X2.889Z1.1702] ok [echo:] ok [echo: ] ok [echo: .9362Z1.1889] error: Expected command letter [echo: X2.9441Z1.192] ok This was toward the end of a 90,000 line G-code file run using the send-response protocol during check mode. Like before, the serial port sniffer confirmed that the line that generated the error is sent correctly with a LF used as an end of line character. but note that GRBL echoes 3 times for that single line and drops the "X2" in the final echo. The serial port sniffer detected no extra end of line characters in the sent data stream. # I'm not sure what to make of this. The above errors, especially the first example is weird and makes me think it may be a GRBL issue, but I am not sure of that. I am running these tests at the absolute maximum speeds that can be run and running files longer than probably anyone else has before, so maybe I am just exceeding the capability of GRBL, or perhaps this is still related to the baud rate issue I reported. As I said, if I slow the streaming loops down with an inserted delay, but with the baud rate kept the same, the errors go away. Last week I had experienced errors that seemed to be tied to baud rate. Indeed those errors did go away when only the baud rate was changed, and this was verified using a simple code within my GUI to compare the original file to the GRBL responses. My new test program uses the same comparison, with the main difference when running being that the new code doesn't include all of the stuff that My GUI implements for canned cycles, tool change support, etc, so the run loop is as streamlined as possible. On my Arduino Nano clones I still haven't been able to generate errors on 250000 baud or 76800 baud, but on my Aruino Mega clone, the opposite is true and the errors appear at 250000 baud, but not at 115200 baud. The Nano uses a ch340G USB to Serial chip but the Mega doesn't, so perhaps the USB chip is the culprit. I'm not sure how to test further, but based on the serial port sniffer program showing that the lines are being sent correctly it seems to me that the error must be either related to the Arduino hardware, or to GRBL code. I am at a loss at this point as to how I can determine which it is, but adding in a slight delay in the streaming loop seems to work ok, but slows things down a bit. Anyone have any ideas?

"On the nano clones I have this test was a little more involved. It didn't simply work with a couple jumper wires like the mega did. The Nano clones I have use the ch340g USB/serial converter. I did find that shorting the pins directly at the ch340g worked, so I figured there must be something in the circuit making the loopback test not work. I couldn't find a schematic for this clone board, but a little poking around with a meter showed that the TX and RX pads from the ch340g were connected to the RX/TX pins of the 328P with a 1 k-ohm resistor in each line just like the 16U on genuine boards. However, the 16U has separate pads to power the indicator LED's. On the ch340g, the LED indicator lamps were being powered from the TX/RX lines with an LED and 1k-ohm resistor. I suspected that the LED/resistor circuit might be pulling just enough power that just shorting the TX and RX pins together wouldn't work. So, out came my pocket knife and I broke the TX and RX LED's off to eliminate that circuit. It worked and the loopback test was working."

septillion · August 4, 2017, 2:43pm

Ahh, then I'm just lucky with my Uno with CH340. Think they place the TX led more sensible (aka, not AFTER the fricking 1k). Can't tell now, between houses aka everything (except from a couple of Pro Mini's) is packed in boxes. No lab atm

But it would have been nice to explain that in you answer...

kprims · August 4, 2017, 3:03pm

"But it would have been nice to explain that in you answer."

I only found out about the TX Led and 1K ohm resistor (Google) after you called nonsense on the idea.

Well, I thought people on here who recommend the newbies make sure they have the ch340 drivers installed and run the Loop-Back test would know better than this old guy/me.

I still wish a couple of people with ch340 Uno's/Nano's would try the Loop-Back test and report success or failure.

I did install IDE 1.8.3 on my granddaughter's Win 10 computer and have the same failures there as on Linux.

X0R · December 6, 2018, 2:57am

kprims:
"But it would have been nice to explain that in you answer."

I only found out about the TX Led and 1K ohm resistor (Google) after you called nonsense on the idea.

Well, I thought people on here who recommend the newbies make sure they have the ch340 drivers installed and run the Loop-Back test would know better than this old guy/me.

I still wish a couple of people with ch340 Uno's/Nano's would try the Loop-Back test and report success or failure.

I did install IDE 1.8.3 on my granddaughter's Win 10 computer and have the same failures there as on Linux.

I know I'm a little late to the party, but I can confirm removing the LEDs causes the Nano clones with the CH340 to work.

Being an old guy too, I used my microscope/hotair station and tried this:

Removing only resistors, didn't work
Shorting empty resistor pads, didn't work
Removing both TX/RX LEDs, WORKED!

Wasted HOURS yesterday trying to get this to work with a brand new Nano clone that I hadn't tested when I bought it. I had been using another Nano clone from the same place which was working until I somehow fried it. It wasn't a good day yesterday.

EDIT: Let me clarify, the LOOPBACK test works, I still can't burn the bloody bootloader...

kprims · December 6, 2018, 3:28am

I still can't burn the bloody bootloader.

Thanks for checking the Loopback.

What are you using to burn the Bootloader and what error are you getting?

X0R · December 6, 2018, 4:00am

kprims:
Thanks for checking the Loopback.

What are you using to burn the Bootloader and what error are you getting?

I tried using the New Bootloader too. Its been about 6 months since I originally did this so I don't remember exactly what I did the first time. I didn't/don't have any other Arduino devices, so I didn't use one device to program another.

Arduino: 1.8.7 (Windows 7), Board: "Arduino Nano, ATmega328P (Old Bootloader)"

C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -carduino -PCOM17 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m 

avrdude: Version 6.3-20171130
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : COM17
         Using Programmer              : arduino
         Overriding Baud Rate          : 19200
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 1 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 3 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 4 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 5 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 6 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 7 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 8 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 9 of 10: not in sync: resp=0x46
avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_getsync() attempt 10 of 10: not in sync: resp=0x46

avrdude done.  Thank you.

Error while burning bootloader.

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

kprims · December 6, 2018, 3:19pm

I tried using the New Bootloader too. Its been about 6 months since I originally did this so I don't remember exactly what I did the first time. I didn't/don't have any other Arduino devices, so I didn't use one device to program another.

If you are trying to burn a bootloader then you have to use another device to do it. I use a cheap Usbasp and like it much better than using an Arduino as ISP.

" To burn the bootloader:

Obtain an AVR ISP, USBtinyISP, ParallelProgrammer, or another Arduino board. This will be your ISP.
Unless otherwise instructed, connect the ISP to the ICSP pins on your board.
Power your board with either a USB cable or an external power supply.
Open up the Arduino IDE.
Make sure you selected the correct board that you are burning to at Tools ► Board ► in the IDE. Double-check this even if you could upload programs correctly; uploading doesn't always require the right board.
Select the appropriate programmer at Tools ► Programmer ►.
Click Tools ► Burn Bootloader, and wait. It shouldn't take more than a minute, and often takes only a few seconds."

Google is your friend.

Djongambo · December 23, 2018, 7:52pm

X0R:
...
3) Removing both TX/RX LEDs, WORKED!
...

I can confirm that issue. Had the same problem with an Arduino Nano clone with CH340. Removing the TX/RX LEDs made the loopback test working. With RX/TX LEDs: loopback test was NOT working. I've just a cutter knife for removing the LEDs :-[

Thanks for the hint!

system · May 5, 2021, 4:15pm