For work, we've developed a lot of test and manufacturing gear that uses Arduino as the controller. Recently, I started using Leonardo (rather than Uno) as the base. It's all running well, until we try to connect it to the Linux servers that we use in manufacturing. They're running CentOs 5.3, and they don't see the serial port on the board. That makes them just about useless.
Hunting around on the web only turned up the fact that the latest version of Ubunu (13.04) did work with Leonardo, so that points to a driver problem.
When Leonardo first powers on, the boot loader looks like a serial port, and comes up at /dev/ttyACM0. If no one has tried to download new code before the timeout expires, the board resets the USB interface, and comes back with a multi-endpoint device. The first is a HID, and is recognized as a Mouse/Keyboard. The second is a cdc_acm device, but with a VID:PID that the older cdc_acm drivers don't recognize. The solution is to give them an update.
If you're a command line type, you can enter
echo 0x1b4f 0x9204 > /sys/bus/usb/drivers/cdc_acm/new_id
If you prefer the automagical solution, create a file /etc/udev/rules.d/46-arduino.rules, and put the following two lines in it:
BUS=="usb", SYSFS{idVendor}=="1b4f", SYSFS{idProduct}=="9204", RUN+="/sbin/modprobe cdc_acm"
BUS=="usb", SYSFS{idVendor}=="1b4f", SYSFS{idProduct}=="9204", RUN+="/bin/sh -c 'echo 0x1b4f 0x9204 > /sys/bus/usb/drivers/cdc_acm/new_id'"
Reboot, and you should be all set.
Friday, July 12, 2013
Thursday, June 20, 2013
Repair of a tektronix TDS544A
I've come into possession of an old oscilloscope, a Tek TDS544A. While it may have been made in 1993, it's still a damn fine scope, and it seems a shame to trash it, esp. since of these failing scopes are easy to fix.
Rummaging around the Tek forums, I found some very useful information. First off was that this series of scopes had a well known problem with leaking electrolytic capacitors. Mine clearly had the leaks. Removed all of them (soldering tweezers really help), scrubbed the board with Simple Green, washed and dried it, and re-capped it. This removed the vast majority of failures, leaving just a calibration check failure (I'm not surprised that the NVRAM battery is likely dead), and a FIFO failure.
Secondly, I found the component-level schematics for a different scope in the family (TDS520B) which is close enough to let me start trouble shooting.
Using an old HP logic analyzer (probably from the 80's), I started looking at the FIFO chip, an HCT7201. Writes to the chip look good - 512 byte writes that cycle from 0x00 - 0xff twice. The empty (!E) and full (!F) flags seems to be toggling at the right times, and so I'm cautiously optimistic that the writes are being correctly handled. (Of course, I have no way to know that the data is being stored correctly, but that's why I've ordered a replacement part.) The scope is triggering off the rising edge of !W, and all the transactions there seem fine. One thing to note is that, as one would hope, rerunning the trace clears the buffers, so that only actually captured data is in the buffer when the trace is stopped.
Reads are a different matter. The scope is picking up *lots* of transitions on the !R line, and the data coming out of the FIFO (which I admit is being picked off of at the inputs to a different buffer chip) is crap. First two transactions are 0x42, a lot of 0xFF, and finally 0xfd and 0xfe. The failure mode is "Expected 0x0102, received 0xfefd". My hunch is that the read strobe is being incorrectly asserted. Perhaps it's glitchy, perhaps the address decode is flakely... Dunno yet.
Rummaging around the Tek forums, I found some very useful information. First off was that this series of scopes had a well known problem with leaking electrolytic capacitors. Mine clearly had the leaks. Removed all of them (soldering tweezers really help), scrubbed the board with Simple Green, washed and dried it, and re-capped it. This removed the vast majority of failures, leaving just a calibration check failure (I'm not surprised that the NVRAM battery is likely dead), and a FIFO failure.
Secondly, I found the component-level schematics for a different scope in the family (TDS520B) which is close enough to let me start trouble shooting.
Using an old HP logic analyzer (probably from the 80's), I started looking at the FIFO chip, an HCT7201. Writes to the chip look good - 512 byte writes that cycle from 0x00 - 0xff twice. The empty (!E) and full (!F) flags seems to be toggling at the right times, and so I'm cautiously optimistic that the writes are being correctly handled. (Of course, I have no way to know that the data is being stored correctly, but that's why I've ordered a replacement part.) The scope is triggering off the rising edge of !W, and all the transactions there seem fine. One thing to note is that, as one would hope, rerunning the trace clears the buffers, so that only actually captured data is in the buffer when the trace is stopped.
Reads are a different matter. The scope is picking up *lots* of transitions on the !R line, and the data coming out of the FIFO (which I admit is being picked off of at the inputs to a different buffer chip) is crap. First two transactions are 0x42, a lot of 0xFF, and finally 0xfd and 0xfe. The failure mode is "Expected 0x0102, received 0xfefd". My hunch is that the read strobe is being incorrectly asserted. Perhaps it's glitchy, perhaps the address decode is flakely... Dunno yet.
Subscribe to:
Posts (Atom)