Loop Back Test - Sticky?

Yes please. Make it sticky.

It should be added to the troubleshooting guide as well. The playground also seems to lack a main category devoted to troubleshooting as well. If possible put it on the main page of arduino.cc as well :wink:

And if there's room on the PCB, why not add it to the bottom layer silkscreen as well?

Between steps 3 and 4 one might consider adding something about listening/checking for proper acknowledgment (the nice gong sound) that the PC detected a new USB device connection. A completely dead FTDI or 8u2 converter would fail at this step. Sometime I have them check the arduino IDE comm menu listing before and after plugging in the arduino to make sure a new comm port is created and displayed in the com port menu before proceeding to the serial monitor, to make sure they are selecting the proper comm number in the IDE or PC terminal application.

Lefty

@retrolefty: Thanks. What does Linux do to acknowledge a device insertion? MacOS?

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

Lefty

Re: linux

Unless it is a mass storage device (camera, sd-card, disk...) usually nothing at all. I can't speak for ubuntu though. Of course it will be logged to system log, but the common user usually doesn't care much about that.

And simple things like serial adapters usually just work out of the box anyway :wink:

An FTDI adapter will create something like this in the syslog:

07/25/11 11:25:08 PM	linuxbox	kernel	[25248.700042] usb 2-4: new full speed USB device number 3 using ohci_hcd
07/25/11 11:25:08 PM	linuxbox	kernel	[25248.928051] usb 2-4: New USB device found, idVendor=0403, idProduct=6001
07/25/11 11:25:08 PM	linuxbox	kernel	[25248.928062] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
07/25/11 11:25:08 PM	linuxbox	kernel	[25248.928069] usb 2-4: Product: FT232R USB UART
07/25/11 11:25:08 PM	linuxbox	kernel	[25248.928075] usb 2-4: Manufacturer: FTDI
07/25/11 11:25:08 PM	linuxbox	kernel	[25248.928079] usb 2-4: SerialNumber: A6007nZC
07/25/11 11:25:08 PM	linuxbox	mtp-probe	checking bus 2, device 3: "/sys/devices/pci0000:00/0000:00:02.0/usb2/2-4"
07/25/11 11:25:08 PM	linuxbox	mtp-probe	bus: 2, device: 3 was not an MTP device
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.009207] usbcore: registered new interface driver usbserial
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.009240] USB Serial support registered for generic
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.009298] usbcore: registered new interface driver usbserial_generic
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.009302] usbserial: USB Serial Driver core
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.036587] USB Serial support registered for FTDI USB Serial Device
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037636] ftdi_sio 2-4:1.0: FTDI USB Serial Device converter detected
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037741] usb 2-4: Detected FT232RL
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037747] usb 2-4: Number of endpoints 2
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037753] usb 2-4: Endpoint 1 MaxPacketSize 64
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037758] usb 2-4: Endpoint 2 MaxPacketSize 64
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.037763] usb 2-4: Setting MaxPacketSize 64
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.042236] usb 2-4: FTDI USB Serial Device converter now attached to ttyUSB0
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.042286] usbcore: registered new interface driver ftdi_sio
07/25/11 11:25:09 PM	linuxbox	kernel	[25250.042291] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

The relevant files are:

'/var/log/messages' on openSUSE
'/var/log/syslog' on ubuntu (probably debian as well)

They can be viewed in a text console/terminal with (start this before inserting the device!):

sudo tail -f /var/log/syslog

I'm sure there are GUI tools to show this information as well, but they will vary (drastically) between distributions.

Between steps 3 and 4 one might consider adding something about listening/checking for proper acknowledgment (the nice gong sound) that the PC detected a new USB device connection.

How about a brief description of what to expect added to step #3?

Well considering now that not all OS make a new usb connection sound, how about this?

  1. With board still not plugged in, open the arduino IDE and check the Tools/Serial Port menu and write down the avalible comm ports, and then close the IDE. Plug in the arduino board, open the IDE and again check the Serial Port menu, there should be a new port number avalible that wasn't listed before, and that is the port number you should select. Failure to see a new port number means either a PC USB driver software problem, or a hardware failure with the FTDI or 8u2 serial converter chip on the board, and no need to proceed any further with this test.

I can't decide. When I first started this topic, I envisioned a Loop Back Test as something that would be applied to a board that recently was working correctly but now had a suspect processor.

"Troublesome USB Cable" is also a common occurrence. Your step #3 would certainly help diagnose that problem.

"Failed to Install Driver" is also common. Your step #3 would help.

I prefer a short simple test (10 or fewer steps) with short simple steps (each step is a single action with an expected result; typically one or two sentences). At this moment, I'm leaning towards your step #3 being a separate sticky.

Thoughts?

The connect power of the arduino was crossed out in the instructions above.
Does that mean the arduino does not need an external power supply when just the base unit is plugged into the computer?

It is not mentioned anywhere on the web site!

newbee234:
The connect power of the arduino was crossed out in the instructions above.

Correct. It's impossible to perform a loop-back test unless the board is connected to the computer. If the board is connected to the computer, it is reasonable to use the computer as the source of power.

Does that mean the arduino does not need an external power supply when just the base unit is plugged into the computer?

I don't know what a "base unit" is but I'm going to say "yes".

It is not mentioned anywhere on the web site!

Of course it is. Search for the Power section...

Thanks for the answer.

And you are right about it being in the hardware board section.

Newbe -- just finding my way!

Which instructions are better? Set #1...

  1. Disable the processor. The best option is to remove the processor from the board (with the power removed). If you cannot or would prefer not to remove the processor, connect a jumper wire between RESET and GND. This will hold the processor in reset preventing it from running.

  2. Jumper TX to RX.

  3. Connect the board to the computer. After a brief pause, Windows should produce a device insertion tone. Linux may or may not produce a device insertion tone; an entry will be added to the system.

  4. Start your favourite terminal application. Serial Monitor will work fine.

  5. Ensure your terminal application is connected to the correct serial port. The baud rate is irrelevant.

  6. Type. As you type, the characters should be echoed to the screen. To send data, some terminal applications, like Serial Monitor, require pressing the Enter key or clicking a Send button.

...or Set #2...

  1. Disconnect power from the board

  2. Remove all connections and shields from the board

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

  4. Connect a jumper from the TX pin (1 on the Uno) to the RX pin (0 on the Uno)

  5. Connect the board to your computer. After a brief pause Windows will produce a device-insertion tone if sound is enabled. Linux may or may not produce a device-insertion tone; an entry is added to the system log.

  6. Start your favourite terminal application. Serial Monitor will work fine.

  7. Connect the terminal application to the serial port for your board. The baud rate is irrelevant.

  8. Send data by typing. Everything you type should be echoed back. To send data, some terminal applications, like Serial Monitor, require pressing the Enter key or clicking a Send button. If exactly what you send is echoed back then the board passes the test. This means that the host computer hardware driver, USB cable, and USB to serial converter are all working.

  9. Shutdown the terminal application

  10. Disconnect the board from the computer

  11. Remove the two jumpers

I think I like set #2 better, mostly because of step 2, which is missing in #1set and could be the cause of many comm failures because miswired external connections to pins 0 & 1.

Lefty

I hope I'm not splitting hairs but this is for beginners.

Windows produces a device insertion tone

Not if sound is disabled.

I'd vote for #2.


Rob

retrolefty:
I think I like set #2 better, mostly because of step 2, which is missing in #1set and could be the cause of many comm failures because miswired external connections to pins 0 & 1.

Excellent point. Thanks.

Anything else?

Graynomad:
I hope I'm not splitting hairs...

That is one of my favourite cartoons! ]:smiley: I miss Chuck Jones. Moving on...

Windows produces a device insertion tone ... Not if sound is disabled.

If you (or anyone reading this) can think of a way to reword that step let me know. I'm stuck with variations that are too wordy or difficult to read.

I'd vote for #2.

Thanks.

Anything else?

That'll teach me to open my big mouth.

Yes you have to be careful it doesn't get so complex you need a flow chart. How about

  1. Connect the board to your computer. After a brief pause Windows will produces a device-insertion tone if sound is enabled. Linux may or may not produce a device-insertion tone; an entry is added to the system log.

Rob

Graynomad:
That'll teach me to open my big mouth.

Was it really that painful?

Yes you have to be careful it doesn't get so complex you need a flow chart.

That's what I was talking about. My brain was flooded with ... What about no sound output device? What if the volume is turned down? What if the device is muted? Must be sleep deprivation.

How about

Perfect. #14 modified with the suggestion.

Anything else?

#2.

I amwas tempted to test this - I did not think baudrate was irellevant. But rather than voice an uinformed opinion I tested - and now I know. With hindsight, obvious.

I will do the #2 doing exactly what it says. WIthout enganging too many brain cells (Nice evening here, dusk, beer in hand ... attached picture as proof)

Excellent instructions. I skipped one (by accident) and things did not work - then I did not skip it - and everything worked. It will be interesting to see if the sticky will have many false alarms for the same reason. And no, I cant think of any instruction to add to stop that from happening.

My only comment for possible improvment is that at point 8. If it does echo everything, then the USB/driver/chip is working

(edited this pst to reflect the test was done, rather than just intended)

Graynomad:
That'll teach me to open my big mouth.

Yes you have to be careful it doesn't get so complex you need a flow chart. How about

  1. Connect the board to your computer. After a brief pause Windows will produces a device-insertion tone if sound is enabled. Linux may or may not produce a device-insertion tone; an entry is added to the system log.

Rob

You may also like to add that under linux a new /dev/ttyUSB* device driver will appear.

The reason is that on (at least fedora or redhat) linux the 'messages' file is root only readable for security reasons. where as the existence of a new device driver is something any user can check on. Basically it is a more convenient thing for a user to look for.

Also note that users will need to be members of the right groups to enabled locking for serial communications. That is something that is noted in the web sites software installation and setup page. The step-by-step instructions however can just point to the right web page for that sort of detail.

Msquare:
beer in hand

Looks exotic and foreign. And tasty.

Excellent instructions.

Thanks.

It will be interesting to see if the sticky will have many false alarms for the same reason

With a few years of working technical support under my belt I can say beyond any doubt that there will be false alarms.

My only comment for possible improvment is that at point 8. If it does echo everything, then the USB/driver/chip is working

Excellent! Every story needs a conclusion and mine was certainly missing one.

Post #14 updated...