Loop Back Test - Sticky?

Couldn't you just disconnect the Serial Converter and loop back right there.

What happened when you tried?

"Serial Converter" What converter?

.

+1 for 2

There should be a remark in the loopback instruction showing to the solution found in https://forum.arduino.cc/index.php?topic=492655.0 (removing the RX/TX LEDs from Arduino Nano Clones) to make the serial loopback test work. Would have saved me some hours :wink:

Hi Djongambo, and welcome.

I don't agree with the word "should", and your description to the affected boards ("clones") is too general.

All i've seen so far (i just learned this from your remark), is that this problem only occurs with CH340 USB-Serial chips, under certain circumstances. Also, the datasheet of that chip (click!) doesn't mention RX or TX LEDs anywhere. So connecting these LEDs directly to the i/o pins, is out of specification. But it is a dirty cheap way to have these LEDs anyone using an Arduino wants, so that is what those manufacturers do. You'll choose the cheapest of all clones (i would), so the 0.2 cents they'd need for the extra pair of transistors so this problem goes away, can't be spared.

So first of all this is a problem you get for free when ordering the cheapest board you can find. You can't expect the members of this forum, or Arduino to know all problems with all hardware clones or software clones (or "forks") around the world. But you can point to a problem and its solution if you have one, and request to have that incorporated in threads like these. There's a slight difference between a request and telling someone "what should be".

retrolefty: Don't have a clue, but I'm sure somone around here can tell us. ;)

Lefty

FOr linux, you can go to a command line and type:

lsmod | grep ch340

I think the port would be ttyS01 or something. It is auto-detected in the Arduino IDE under Tools | Port.

to see if the port is enabled. This can only be done while the USB is plugged into the circuit board. THe module unloads if Linux senses that the port is disconnected.

I’d like to suggest adding a point to the loop-back-routine:

“If loop-back fails, you may want to try removing the main microprocessor and try again (not grounding the RST)”

Reason being I was almost certain my MEGA16U2 had failed since I could just not get loop-back or programming to work. By chance, I tried the test with the 328P removed, and it worked. This might help people like me pinpoint an otherwise not so obvious problem.

EDIT: Loopback now working with 328 installed. Confuso. Will investigate further.

AnonAustria13_1: I'd like to suggest adding a point to the loop-back-routine:

"If loop-back fails, you may want to try removing the main microprocessor and try again (not grounding the RST)"

Reason being I was almost certain my MEGA16U2 had failed since I could just not get loop-back or programming to work. By chance, I tried the test with the 328P removed, and it worked. This might help people like me pinpoint an otherwise not so obvious problem.

EDIT: Loopback now working with 328 installed. Confuso. Will investigate further.

More confuzing...Was it a MEGA or a UNO as you mentioned both ?!!?

MEGA16U2 is the Atmel USB to serial solution on board of the most recent (and official) R3 UNOs. The MEGA16U2 is soldered on board, the 328P in a socket so that one is easy to remove. With the 328P removed, it doesn't matter what you do with RESET, the 328P isn't there to interfere with your signals any more (which is why you want to keep that 328P asleep). I can't imagine what the 328P could do to defeat the loopback test, except for a full short to GND with either Rx or TX pin.

On the Uno, Reset on the Power Header, and Reset button, only go to the 328P.
Grounding it does all the Reset stuff, like making all the IO pins go to their Input state, and leaving Rx/Tx totally free for the Loopback test with the 16U2.

I'm pretty sure I figured out what is going on:

If I remember correctly, the chip stopped working after I uploaded some code trying to interface with a temperature probe. I thought I had fried something on the board since TX never lit up again. What I suppose happened was I accidentally pulled TX low doing some DPM (since I can't imagine I'd ever touch 0 and 1 knowingly).

Then, following this guide, I connected 0 to 1 and RST to GND, but used the ICSP1-header which controls the MEGA16U2. Doing this effectively sent the converter into sleep mode, therefore also leading to test failure.

I am now trying to reburn the bootloader, but am running into the same problem where coms don't quite work since TX is still pulled low. Lesson learned: Never ever ever touch GPIO 0 and 1 if you don't exactly know what you're doing!

On that point: Does anyone know how I could still reburn the chip? Is there any kind of backup for such a case?

EDIT: Just realized reburning doesn't use serial connection... Well, this means I'll still need to figure out why the chip dorsn't return a valid signature...

https://www.arduino.cc/en/Tutorial/BuiltInExamples/ArduinoISP

8 Bit Teensy Boards work well as programmers.

Hello Arduino forum,

Have never used a terminal application so a favorite has not yet been identified. Could some information about how to acquire a terminal application be offered?

Thanks.

Allen in Dallas

Google

terminal emulator (your platform i.e. Windows/Mac/. . .)

Snow gone ?


Edit I use "realTerm", PuTTY is good too.

https://realterm.sourceforge.io/

https://sourceforge.net/projects/realterm/

"3. Force the processor to remain in reset by connecting a jumper from RESET to GND."

What about "...jumper or 1k resistor...".

I would prefer to use 1k resistor instead of wire. Just in case to avoid of shortage if something is going wrong or some mistake happen. The 1k is good enough to keep the RESET down if there is 10k pull-up.