Hi All,
Having an odd issue. Trying to connect to the service console on my TDS520 is resulting in corrupt output in my terminal.
Even odder, is the scope seems to boot and run normally. It passes all it's self tests.
The scope has had all it's capacitors replaced previously, and has been working fine for years. Did just run into an issue with the attenuators not selecting correctly, but that turned out to be a bad 74HCT138 on the acquisition board.

I am trying to use my service console adapter I built, but I am getting corrupt output.


Bootrom Header Checksum passed.

Bootrom Total Checksum passed.

BootRom Check Sum passed.

Bus Error Timeout test passed.

Kernel Diagnostics Complete.


Calling SDM (monitor) Routine.


Enabling Bus Control register. Value = 0x67

IMR 1 Register test passed.

Misc. Register test passed.

Timer Interrupt test (Auto-Vector) passed.

NVRam DSACK test passed.

NVRam Write protected.

Flashrom DSACK and JumpCode test passed.

Flashrom Checksums passed.

Bootrom Diagnostics Complete.


Transferring control to the Flashrom.

-> Console Loopback O.K. <-
.

¡
^åñ@ € € €^ñy
ñ € € ñ)
x¼ € € € ñ € €V®oÎk@De§†óÀÚeC@Sž.§Ú
€^^€ € €^Q
€ xy@ ü~ü~ü € øù
€ ø¼ € ^€~~@
€ € ñ å€ € ü~A€ € ñ¼^€ € ~€~ü
€ € ñ €~~€ €~ü
¡
€ € € €V®oÎk@veÎÒoÐ.¸2¡
€ € € €€SGÒpÊd *'Üd±ÞneH½Ú ¥äsiãû.

€ € €CÃÕÚbi@äoŒ äd’Êv äÁ6MÀ1
€ € € Sž.§Ú Jµ@SiOô 1Ð8“ƒ‚äoc$@= àÅ8¡ € € € € ó3Ö IC•ävaô LF€à ]Nfæ,A € € € ½Þtl«@St#ÂgYL¢ôe ’ä6 ×#Êd ÁxÀ0²à

€ € € € „+æh ô àÁ,2ØasºÂitŒèa§æ ’€(Mš®Œ’Êg ‚àb4
IÐ € € € ,ŠRª˜: %ÊB@v®NóÜ Lp€GCžMPªˆ

€ € € € ÈòriC@1ŽŠ´20Ä,PÊkGÞn± R3\
€ € € ´…Èe ãt ¥È FÄ2 Œ
‡Àè50@M¨ 1Ž’¸

€ € € €coòršC@W‹@Ri§É@SyW¦3± R3\,Ä9Ø,Ä9Ü,Ä9à,Ä9ä
¡PðeL'ã@Di˜–óætš¬ŽÐStart Power-On Diag Sequence
hwAccountant probe routines
Probe for unexpected pending ints
Dsp Instr mem size
Dsp D2 mem size
Dsp D1 mem size
Dsy Vect0 mem size
Dsy Vect1 mem size
Dsy Wfm0 mem size
Dsy Wfm1 mem size
Dsy Text0 mem size
Dsy Text1 mem size
Acq number of digitizers
Acq mem size
Cpu timer interval uSec
Cpu Dram size
NvRam mem size
Opt RS232/ Cent presence
dspForcedBus ................... pass
cpuDiagD2MiscReg ............... pass
cpuDiagDSPIntMaskReg ........... pass
cpuDiagDsyAccess ............... pass
dsp68kMemTest .................. pass
cpuDiagFIFOMem ................. pass
dspRunVerify ................... pass
dspBusRequestTest .............. pass
dspImplicitBusAccess ........... pass
dspTristarMemTest .............. pass
dsyDiagResetReg ................ pass
dsyDiagVscReg .................. pass
dsyDiagPPRegMem ................ pass
dsyDiagRasRegMem ............... pass
dsyDiagRegSelect ............... pass
dsyDiagRamdacRegMem ............ pass
dsyDiagAllMem .................. pass
dsySeqYTModeV0Intens ........... pass
dsyDiagSeqXYModeV1 ............. pass
dsyRastModeV0Walk .............. pass
dsyRastModeV1Attrib ............ pass
dsyWaitClock ................... pass
cpuDiagAllInts ................. pass
optRS232DuartIO ................ UNTESTED
nvLibrariansDiag ............... pass
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
acqProcThermistor .............. pass
digDiagD1Conf .................. pass
digDiagConf .................... pass
extTrigRegDiag ................. pass
vertRegDiag .................... pass
cvrRegDiag ..................... pass
trigSrcRegDiag ................. pass
lstlDiag ....................... pass
ctlDiag ........................ pass
trigAcqRstDiag ................. pass
logicTrigConfDiag .............. pass
alphaEdgeTypeComp .............. pass
lineTrigDiag ................... pass
dlyTrigDBETrigAfter ............ pass
dlyTrigDBTRunsAfter ............ pass
glitchTrigDiag ................. pass
pulseWidthDiag ................. pass
vertAttenStrobeDiag ............ pass
vertAttenShiftReg .............. pass
dacRangeDiag ................... pass
fpDiagConf ..................... pass
E•Æutë@Sm‹CÂlkAøhwAccountant probe routines
Probe for unexpected pending ints
Dsp Instr mem size
Dsp D2 mem size
Dsp D1 mem size
Dsy Vect0 mem size
Dsy Vect1 mem size
Dsy Wfm0 mem size
Dsy Wfm1 mem size
Dsy Text0 mem size
Dsy Text1 mem size
Acq number of digitizers
Acq mem size
Cpu timer interval uSec
Cpu Dram size
NvRam mem size
Opt RS232/ Cent presence
[SG¥àpeØðW#­æ]:(
J+ØltX³^VLÕÜ V®Nëã@1’(
CåäigC(¨ˆä90<‰Ôec¢ÊchóØoV@In§änX'óãÂl 3\
Ã
CË¡ÉÒppØðW#­æ]:þ

ËEäipÊdØá®orÍut
CË¡ÉÒppØðW#Ös]þ?
CA ü € € € € € €-ÀÉÒntÐÐi°¥æt
"@adÎmXn] € € € ´ &kàla´Êm#å

Èrs € € € € €-tÞdi&mY›#å

Èrs¸Äy§ÍX v«Ê -2Òll´•Úor¡ À@ € € € € € € ÀäiClëÞ

́ € € € € € €-´•ÚShs
”@ € € € € € €€ KÀÈÒnt˜…èal”áÆep'óÜ
’@ € € € € € ´ N–ÞotA¤@ € € € € € €-¥æpl˜a]çÓ²Êct#aFÊsNf
Œ € € € €€ € ´ ÌãÍÞle˜ÉÞntÀ„ÜelÕÚp
Š€ € € € € € € šÆop™ÊcM«
Ë¡ÈÒppØðW#­æ]:þ

Any ideas on where to start looking?

I would check the following:
Number of data bits, parity setting, number of stop bits, terminal emulation type (vt100)

Putty on win10 worked for me.

Leo

I am using putty, with 9600 8-n-1, RTS/CTS flow control

If I remember correctly I used no flow control, or maybe xon/xoff.

Would try without first.

Leo

Flow control may not be the answer, you'd just be missing characters without it.

It looks as if one part of the program is using different settings, either baudrate or bit count and parity.

I've seen characters like that when baudrates don't match.

In some applications (ESP-8266 for instance), the boot routine uses a fixed baudrate, while the normal communications routine can use a selected baudrate.  This could be the case here.

Harvey

You're right, flow control might not be it.

Maybe try the terminal at 19200 bd, and see if the other parts are legible ?

Leo

I will give it a shot tomorrow, but I don't believe the rate changes, as this service console for repairing the scope, independent of the uart for general use.

IIRC it also used to work at 9600 baud just fine, last time I used the port

On Fri, Jan 28, 2022 at 08:15 PM, <silverchris@gmail.com> wrote:

I will give it a shot tomorrow, but I don't believe the rate changes, as this
service console for repairing the scope, independent of the uart for general
use.

IIRC it also used to work at 9600 baud just fine, last time I used the port

------
It almost looks like RX line is floating between module executions. You can try adding 5k-10k termination resistor to RS232 RX line. Usually it is implemented in the interface IC but still worth a try.
Ozan

Think I figured it out.

I bought a brand new XR68C681 which is a modern version of the SCC68681. Both of them claim compatibility with the MC68681, which is what the scope was designed with in mind.

The XR68C681 and SCC68681 MR1A/MR1B register is slightly different than the MC68681.

The MC68681 uses 2 bits for the stop bit setting, with 0 0 being 1 stop bit

The XR68C681/SCC68681 use 4 bits for the stop bit setting. With 0 0 0 0 being 0.563 stop bits

As you may have guessed, my UART to serial IC does not like the 0.563 stop bits, which is only an issue when the XR68C681 is sending rapidly. If it's sending slowly, the stop bit length doesn't really matter, as the stop bit is high, just like the idle state of the TX line. This is why the text came through clearly in parts, and slowly in others.

Using SIGROK, I captured the proper boot text for reference, as well. I have included that at the end of this post.

Now I just need to figure out a solution. I guess one option is to buy some used/old stock MC68681 from ebay, though I don't exactly trust that option



Bootrom Header Checksum passed.

Bootrom Total Checksum passed.

BootRom Check Sum passed.

Bus Error Timeout test passed.

Kernel Diagnostics Complete.


Calling SDM (monitor) Routine.


Enabling Bus Control register. Value = 0x67

IMR 1 Register test passed.

Misc. Register test passed.

Timer Interrupt test (Auto-Vector) passed.

NVRam DSACK test passed.

NVRam Write protected.

Flashrom DSACK and JumpCode test passed.

Flashrom Checksums passed.

Bootrom Diagnostics Complete.


Transferring control to the Flashrom.

-> Console Loopback O.K. <-
.




^^^^ ^^^^

^^ ^^

^^ ^^ VxWorks Development System

^^ ^^

^^ ~~~~~~~~ ~~

^^ ^^ ~~~ ~

^^ ^^ ~~~

^^^^ ~ ~~~

^^ ~~ ~~~



VxWorks version 4.0.2.

Stripped Stand Alone Rom Version.

Columbia Proc. Brd. Rev GG065801

System Ram Size = 1048576, Proc ID = 0x18

Clock Interval = 13108 usecs,

Bootline Storage Size = 296 stored @0x4000068

Flash ID = 0x0, Flash Wait states = 2 (Misc. reg = 0x14),

KERNEL: WIND version 1.0. GCC COMPILED

Copyright 1991-2001, Tektronix, Inc.

made on: Wed Feb 12 15:28:50 PST 1992.

copyright Wind River Systems, Inc., 1986, 1987, 1988, 1989


Executing Diagnostics

Start Power-On Diag Sequence
hwAccountant probe routines
Probe for unexpected pending ints
Dsp Instr mem size
Dsp D2 mem size
Dsp D1 mem size
Dsy Vect0 mem size
Dsy Vect1 mem size
Dsy Wfm0 mem size
Dsy Wfm1 mem size
Dsy Text0 mem size
Dsy Text1 mem size
Acq number of digitizers
Acq mem size
Cpu timer interval uSec
Cpu Dram size
NvRam mem size
Opt RS232/ Cent presence
dspForcedBus ................... pass
cpuDiagD2MiscReg ............... pass
cpuDiagDSPIntMaskReg ........... pass
cpuDiagDsyAccess ............... pass
dsp68kMemTest .................. pass
cpuDiagFIFOMem ................. pass
dspRunVerify ................... pass
dspBusRequestTest .............. pass
dspImplicitBusAccess ........... pass
dspTristarMemTest .............. pass
dsyDiagResetReg ................ pass
dsyDiagVscReg .................. pass
dsyDiagPPRegMem ................ pass
dsyDiagRasRegMem ............... pass
dsyDiagRegSelect ............... pass
dsyDiagRamdacRegMem ............ pass
dsyDiagAllMem .................. pass
dsySeqYTModeV0Intens ........... pass
dsyDiagSeqXYModeV1 ............. pass
dsyRastModeV0Walk .............. pass
dsyRastModeV1Attrib ............ pass
dsyWaitClock ................... pass
cpuDiagAllInts ................. pass
optRS232DuartIO ................ UNTESTED
nvLibrariansDiag ............... pass
calLibrarianDefaultCk .......... pass
dspForcedBus ................... pass
acqProcThermistor .............. pass
digDiagD1Conf .................. pass
digDiagConf .................... pass
extTrigRegDiag ................. pass
vertRegDiag .................... pass
cvrRegDiag ..................... pass
trigSrcRegDiag ................. pass
lstlDiag ....................... pass
ctlDiag ........................ pass
trigAcqRstDiag ................. pass
logicTrigConfDiag .............. pass
alphaEdgeTypeComp .............. pass
lineTrigDiag ................... pass
dlyTrigDBETrigAfter ............ pass
dlyTrigDBTRunsAfter ............ pass
glitchTrigDiag ................. pass
pulseWidthDiag ................. pass
vertAttenStrobeDiag ............ pass
vertAttenShiftReg .............. pass
dacRangeDiag ................... pass
fpDiagConf ..................... pass
Executing Smalltalk

hwAccountant probe routines
Probe for unexpected pending ints
Dsp Instr mem size
Dsp D2 mem size
Dsp D1 mem size
Dsy Vect0 mem size
Dsy Vect1 mem size
Dsy Wfm0 mem size
Dsy Wfm1 mem size
Dsy Text0 mem size
Dsy Text1 mem size
Acq number of digitizers
Acq mem size
Cpu timer interval uSec
Cpu Dram size
NvRam mem size
Opt RS232/ Cent presence
[Stripped vxWorks]:

Smalltalk/V Sun Version 1.12

Copyright (C) 1990 Object Technology International Inc.

Nope, looks like I am completely wrong on that. I managed to dig up an old datasheet for the MC68681 and it has the same register structure and stop bit settings as the modern XR68C681. I also dug out a MC68681 to test, and it has the same issue

Can anyone with the correct tools grab a capture with another scope or logic analyzer? My capture shows during some parts, notably the VxWorks logo, that the stop bit is 59us where the normal bit length is 104us. That does work out to the 0.563 stop bit setting.

Here is a photo of a capture I took
https://i.imgur.com/4tyaM9Y.png

After further digging. I think there is a small bug in the firmware of the scope.

For the Console loop back test the scope preforms at boot, it has to change the setting in MR2A to enable the internal loopback in the 68681. After it preforms the test, instead of setting the MR2A register back to 0x37 which it was set to before the loopback test, it sets it to 0x00. This sets the 68681 to the 0.563 stop bits (Why this is a feature of the chip is beyond my understanding...), I think it also breaks flow control.
I have confirmed this both by taking a logic analyzer to the bus, and with some reverse engineering of a firmware dump I took from my machine. I would be curious if this issue is in all the firmware for it.

Now, as to why other people haven't seen to have noticed this before... It seems the CH340E I am using for serial to usb can't cope with the shortened stop bits. Trying it with a FTD232, it works fine. Guess I will need to design up a new board with a different serial to usb chip.

It seems the CH340E I am using for serial to usb can't cope with the shortened stop bits. Trying it with a FTD232, >it works fine. Guess I will need to design up a new board with a different serial to usb chip.

I don't think that's a real serial port driver/receiver that supports true +-12VDC serial interfaces. Have a look at the VIO spec in the datasheet -.5VDC to VCC+.5VDC.

Jay

If you do it right, yes.  However, some microcontrollers used a simple transistor as an input, so anything negative turned off the transistor, and anything sufficiently positive turned it on.  I think that some outputs managed to do that, but the input threshold on most true RS-232 receivers tries to ignore anything that's not sufficiently negative.  Depends on what the intended receiver was.

If it's really a true RS-232 system, then receivers and drivers are indicated.  The traditional ones needed a +/- 12 or 15 volt supply.  The MAX series had internal charge pumps and used 4 capacitors to derive the higher + and - voltages.  IIRC, they'd run from +3.3 or +5.

Harvey

There is no RS232 level translation involved, as I am connecting the USB UART directly to the 68681, both of them use 5V TTL.

Also, a MAX232 wouldn't resolve the issue of the short stop bit, as it is just level translation, it doesn't alter the bitstream

I use one of these:
https://www.eevblog.com/forum/testgear/console-port-debug-adapter-for-tek-tds500-tds600-and-tds700-series-scopes/

No null modem cable is needed, but you need the serial / parallel port option in the scope.

Jay

I don't have the Centronix/RS-232 board. I have made my own board with the XR68C681, and the CH340E.


If you have built an adapter, would it be possible for you to capture a trace of the scope transmitting a character on the console, after it has booted? Hooking the adapter up, and scoping the TX (Pin 33 on the 68681) line from the scope, and sending the character "U" would probably be best, as it is 01010101 in binary. It should be easy to see the width of the stop bit that way.