Go Down

Topic: Arduino failing loopback test despite working perfectly otherwise (Read 857 times) previous topic - next topic

AleksandurMurfitt

Aug 01, 2017, 11:01 pm Last Edit: Aug 02, 2017, 12:57 am by AleksandurMurfitt
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

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

@kprims, nonsense! Loopback test works on every serial communication.
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

AleksandurMurfitt

@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

#4
Aug 02, 2017, 07:11 pm Last Edit: Aug 03, 2017, 01:13 am by kprims Reason: Add URL:Add more Information
"@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.

https://github.com/grbl/grbl/issues/845

"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

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...
Use fricking code tags!!!!
I want x => I would like x, I need help => I would like help, Need fast => Go and pay someone to do the job...

NEW Library to make fading leds a piece of cake
https://github.com/septillion-git/FadeLed

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.

X0R

"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:

1) Removing only resistors, didn't work
2) Shorting empty resistor pads, didn't work
3) 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

Quote
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

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.

Code: [Select]
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

Quote
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.

Go Up