EEVblog Electronics Community Forum
Electronics => Repair => Topic started by: amaschas on November 06, 2024, 11:52:20 pm
-
Hey all, I've been working on debugging a stubborn issue with a TDS 745C scope, and it's been suggested that I can get some useful debug information out of the TDS debug port. I got my hands on the adapter documented in this thread: https://www.eevblog.com/forum/testgear/console-port-debug-adapter-for-tek-tds500-tds600-and-tds700-series-scopes/ (https://www.eevblog.com/forum/testgear/console-port-debug-adapter-for-tek-tds500-tds600-and-tds700-series-scopes/)
I also have a number of serial/USB adapters lying around, and I've tried several of them with this adapter, but I haven't managed to get an output from the scope. In fact, the scope exhibits the behavior reported in that thread where it won't boot at all. My process is:
1) Connect the serial/USB adapter to my computer.
2) Connect to the adapter via picocom -b 9600 /dev/ttyUSB0 -f h
3) Verify the picocom configuration:
*** baud: 9600
*** flow: RTS/CTS
*** parity: none
*** databits: 8
*** stopbits: 1
*** dtr: up
*** rts: up
*** mctl: DTR:1 DSR:0 DCD:0 RTS:1 CTS:0 RI:0
4) Boot the scope
The scope remains stubbornly blank, apparently waiting for some serial signal I have failed to send, though I believe that RTS/CTS flow control is all that is required. For sanity's sake, I shorted the CTS and RTS pins to each other, and this did in fact get the scope to boot, but rather than debug info I just received gibberish over the serial connection (the random question marks and escape characters that generally show up with an incorrect baud rate). What's really interesting about this, is that the gibberish continued even after I turned the scope off, so I'm wondering if I'm running into some sort of buffering behavior? My next step is to plug in am FTDI USB/serial breakout with RTS/CTS pins exposed and see if I can get any useful debug information via a logic analyzer, but I'm hoping someone here might have some clue as to what is going on.
[edit] Used my logic analyzer, and I am in fact observing readable ASCII output. However I get no output on the serial client for some reason. However, I was playing around and reversed TX/RX, and suddenly the serial client started outputting gibberish, though at a rate that indicates I was just seeing the garbled debug output. So garbled output with the pins reversed, no output with the pins in the correct spot.
-
So I am completely out of ideas. I know this thing is communicating properly because I can see it on the logic analyzer, but any serial client I try produces no output. If anyone has a sense of what's going on here I'd love a hint. I have a feeling its something to do with my shorting RTS to CTS, like maybe the serial client doesn't know to receive, but I don't have a great sense of what would make it work properly.
-
I have a bunch of these scopes.
Can you provide the pinout of your adapter? I'll rig up my own and have a poke at things with one of my scopes next week.
-
Not familiar with this specific debug adapter/scope series, but your comment about reversing RX/TX and the handshake not working (plus the RS232 port on the scope being male in the pictures in the linked thread) to me sounds like you need a null-modem cable (with full handshake) between your scope and the serial adapter...
-
Thank you both for offering to help! I jumped back onto this today and pretty much immediately solved the issue. The problem was that the little DB9 breakout I was using, which claiming to do level shifting did no such thing when I thought to open the case. I added a MAX3232, shorted RTS to CTS, and got serial output no problem. Really a very annoying and potentially catastrophic case of false advertising, and a powerful reminder to always check voltage levels thoroughly. Luckily nothing I was using to try to diagnose suffered from the higher voltages, so it could have been worse.
-
The blue serial converter is 99% not RS232 compatible.
It is a cheap fake FT232 connected directly to an DB9 connector. level is TTL.
[attachimg=1]
-
Good to see you got it figured out! And a good thing to keep in mind for future debugging. :)