v3.4.0-dev.9 regression: SC126: minicom shows garbage characters on connection

[skullandbones]

@wwarthen I note that you have changed the CTS operation in v3.4.0-dev.9 and I think that has caused a side-effect with minicom.

minicom has hardware flow control enabled.

The steps are:

1. Power-up my SC126 Z180 board by connecting Linux USB cable to SC126's USB to serial adaptor
2. After 5 seconds, start minicom
3. minicom sometimes shows garbled characters as follows:

   
   Welcome to minicom 2.7.1

OPTIONS: I18n Compiled on May 6 2018, 07:48:54. Port /dev/ttyUSB1, 18:47:58 ÅŒ²êÒ ꅚÂjrÂr¢jL-A Z for help on special keyWW.¤ª¨L&¤«ª(«LN ÁjRjUÕ éÕi ����©é ÒÔҫ S V)bjªÒÕiHhU+ԋ RÊRê銊T$&KH­L

minicom can get confused and misinterprets garbled characters as control information.

Pressing the return key unexpectedly enters the monitor:

Loading Monitor...

Monitor Ready (? for Help) 8E>

I would of expected the bootloader menu to be reprinted which suggests that the bootloader received garbage characters.

Prior to  v3.4.0-dev.9, minicom would not capture the bootloader messages because minicom is started after the board starts-up. Then pressing the return key reprinted the bootloader menu as expected.

If I hit the reset button on the SC126, then the bootloader messages are shown and the bootloader menu operates as expected.

So I suspect that the change to the CTS operation has triggered a regression.

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

Well, I was wondering if there might be any side effects from this change. However, I am totally mystified by your symptoms.

So, first of all, are you connecting via the SC126 built-in ASCI ports? I would expect you are. The CTS change you are referring to is primarily a change to the UART driver which shouldn't apply in your case.

There were two other related changes made at the same time. One of these might be affecting you:

1. Removed code that suppressed hardware flow control during HBIOS startup. The removed code included a reset of the console port just before launching the Boot Loader. The removed code was introduced in v3.2.1, so this really just restored things to the way they were in v3.2 and prior.
2. Enabled hardware flow control by default. For most drivers (including ASCI) this was not a change because they were hard coded to use hardware flow control. However, in the case of ASCI, it did mean that outbound CTS flow control was now enabled whereas it was not before.

One (or both) of the items above may have something to do with your symptoms. Although I'm not sure why.

Why are you waiting to start minicom until after plugging your USB serial adapter into SC126? As long as the adapter is plugged into your Linux machine it should be available to minicom. It is definitely preferable to have your console terminal up and running before powering up or resetting your SC216. If possible, I would like to see what happens if minicom is already running when you plug your adapter into the SC126. I would also be interested to know what happens if you hold down the reset button on SC126 while plugging in the serial adapter, start minicom, then release the reset button.

I am trying to recreate your problem, but so far everything seems fine. I am using minicom on Ubuntu. My SC126 is powered by a wall adapter, so it is a bit different. But I also tried my SC131 which is virtually identical to a SC126 and is powered by the serial adapter (like yours). I see no problems if I start Tera Term before or after plugging in the adapter. Here is a session log produced when I start minicom after plugging in the adapter:

Welcome to minicom 2.8

OPTIONS: I18n 
Port /dev/ttyUSB0, 13:12:10

Press CTRL-A Z for help on special keys

CI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
INTRTC: Wed 2020-01-01 00:00:00
MD: UNITS=2 ROMDISK=384KB RAMDISK=352KB
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: SDXC NAME=SL64G BLOCKS=0x076F5000 SIZE=60906MB

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          352KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      SD0:        SD Card           60906MB,LBA

Small Computer SC131 [SCZ180_sc131] Boot Loader

Boot [H=Help]: 

Other than missing characters at the start (totally expected in this scenario), my startup is clean.

I'm struggling with how to proceed with this. It's hard to imagine that invalid characters are being pushed out the serial port. If so, that would be affecting me (and many others). In my next code check-in, I am restoring the code that I recently removed, but it is bracketed with conditional compilation. There is an equate at the top of hbios.asm that controls the inclusion of the code. You can change this from FALSE to TRUE and then build a ROM. This will allow you to confirm whether or not this change is causing your symptoms.

It is quite common for garbage characters to be introduced on a serial line when it is connected/disconnected. I suspect that is what is happening in your case, but my recent changes are somehow exposing them.

[wwarthen]

Hi @skullandbones,

I'm struggling with how to proceed with this. It's hard to imagine that invalid characters are being pushed out the serial port. If so, that would be affecting me (and many others). In my next code check-in, I am restoring the code that I recently removed, but it is bracketed with conditional compilation. There is an equate at the top of hbios.asm that controls the inclusion of the code. You can change this from FALSE to TRUE and then build a ROM. This will allow you to confirm whether or not this change is causing your symptoms.

RomWBW Development Snapshot v3.4.0-dev.10 has the SUPCTS equate at the top of hbios.asm as described above.

Thanks,

Wayne

[skullandbones]

@wwarthen here are some more observations using v3.4.0-dev.9 on my SC126 Z180 board.

There is a human race condition between me connecting the USB cable to the USB to serial adaptor, starting minicom and seeing or not seeing garbled characters in minicom.

I note that there is about a 3 second delay between external power being applied and the bootloader textual messages being transmitted. I can observe this delay by using an external 5V power supply connected to the SC126 so not using power from the USB to serial adaptor. The adaptor is connected to minicom and minicom is started before the board is powered-up.

Using the USB to serial adaptor to power the SC126, I am sometimes fast enough to connect the USB cable and to start minicom inside that 3 second delay period. In this case, there is no garbled text and the bootloader textual messages look OK and the bootloader menu is shown waiting for input. In addition, all 8 status LEDs on the SC126 are illuminated when waiting at the bootloader menu prompt. Pressing return turns off the LEDs. This is the normal behaviour.

On the other hand, when I take longer than 3 seconds to start minicom, I get the garbled characters. This is consistently occurring.

With minicom not running, I connect the USB cable to the USB to serial adaptor, I observe the 8 status LEDs on the SC126 board. LEDs 0 to 4 quickly light-up in turn, short pause then LEDs 5 and 6 illuminate. However, LED 7 is off. I think this is a clue as LED 7 normally comes on prior to the bootloader messages being transmitted. After the garbled characters are shown, then all the status LEDs turn off indicating something had been received. Now the board is in monitor mode as shown by pressing return.

I am unable to start minicom earlier because I have to wait for the USB enumeration phase of the USB to serial adaptor to complete to register device node /dev/ttyUSB1.

Reception of garbled text can be caused by

1. Mismatch in Baud Rates between the transmitter and receiver.
2. Reception started part way through a transmitted character (improper framing).
3. The continuously transmitted data stream has ambiguous framing as the perceived received start bit is really a data bit (improper framing).

Without minciom running, the USB to serial adaptor may have incompatible settings to the SC126 because the adaptor has not yet been configured. Therefore, when the adaptor receives characters the reception becomes garbled. These adaptors have small buffers perhaps a few hundred bytes.

Subsequently, when minicom connects to the adaptor, the small buffer of garbled characters is read by minicom causing minicom to malfunction. However, I would of expected this buffer to have been cleared when opening /dev/ttyUSB1 but perhaps that is not the case.

I will try to get some more results using your v3.4.0-dev.10

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

There is a human race condition between me connecting the USB cable to the USB to serial adaptor, starting minicom and seeing or not seeing garbled characters in minicom.

Hmmm... your setup must be different than I am imagining. Is your USB-to-Serial adapter connected to your SC126 in some way that it cannot be disconnected? Not clear why you can't have the entire USB-to-serial setup fully connected to your Linux box first. Start minicom. Then, last step, plug the USB-to-Serial adapter into your SC126.

I note that there is about a 3 second delay between external power being applied and the bootloader textual messages being transmitted. I can observe this delay by using an external 5V power supply connected to the SC126 so not using power from the USB to serial adaptor. The adaptor is connected to minicom and minicom is started before the board is powered-up.

OK. Yes, the delay is normal. It takes a couple seconds to dynamically detect the system speed.

Using the USB to serial adaptor to power the SC126, I am sometimes fast enough to connect the USB cable and to start minicom inside that 3 second delay period. In this case, there is no garbled text and the bootloader textual messages look OK and the bootloader menu is shown waiting for input. In addition, all 8 status LEDs on the SC126 are illuminated when waiting at the bootloader menu prompt. Pressing return turns off the LEDs. This is the normal behaviour.

On the other hand, when I take longer than 3 seconds to start minicom, I get the garbled characters. This is consistently occurring.

This is interesting and I think I see what might be happening. The USB-to-Serial adapters have pretty large buffers in them. Additionally, the adapter is where the baud rate is actually set. Let's say that the adapter starts up with a baud rate other than 115200 by default. It could receive some data at the wrong baudrate prior to minicom being started. It would buffer this invalid data. Once minicom starts, it would receive the invalid data because it was buffered before minicom could "fix" the baud rate.

With minicom not running, I connect the USB cable to the USB to serial adaptor, I observe the 8 status LEDs on the SC126 board. LEDs 0 to 4 quickly light-up in turn, short pause then LEDs 5 and 6 illuminate. However, LED 7 is off. I think this is a clue as LED 7 normally comes on prior to the bootloader messages being transmitted. After the garbled characters are shown, then all the status LEDs turn off indicating something had been received. Now the board is in monitor mode as shown by pressing return.

Correct.

I am unable to start minicom earlier because I have to wait for the USB enumeration phase of the USB to serial adaptor to complete to register device node /dev/ttyUSB1.

Still confused with this. I'm not clear why the adaptor cannot be plugged in, enumerated, and minicom started long before ever plugging the adapter into the SC126.

Reception of garbled text can be caused by

1. Mismatch in Baud Rates between the transmitter and receiver.
2. Reception started part way through a transmitted character (improper framing).
3. The continuously transmitted data stream has ambiguous framing as the perceived received start bit is really a data bit (improper framing).

Yup.

Without minciom running, the USB to serial adaptor may have incompatible settings to the SC126 because the adaptor has not yet been configured. Therefore, when the adaptor receives characters the reception becomes garbled. These adaptors have small buffers perhaps a few hundred bytes.

😀 Exactly what I surmised.

Subsequently, when minicom connects to the adaptor, the small buffer of garbled characters is read by minicom causing minicom to malfunction. However, I would of expected this buffer to have been cleared when opening /dev/ttyUSB1 but perhaps that is not the case.

This is a bit of a mystery to me as well. You would need to dive into the specific driver for the USB-to-Serial adapter in Linux to see what it is doing.

I will try to get some more results using your v3.4.0-dev.10

OK, that will be interesting. Don't forget to set the SUPCTS equate -- it is not on by default.

Regardless, I am going to suggest that your core problem is the serial port not being truly ready at the time that the SC126 starts sending data to it. This is always going to be problematic.

Maybe you could post a picture of your adapter connected to your SC126 so I can understand better.

Thanks,

Wayne

[skullandbones]

@wwarthen Looking in more detail to the connections on the USB to serial adaptor, I note that the DTR line (output) from the adaptor is connected to CTS (input) of the SC126 board. Therefore, RTS (output) from the adaptor is not connected.

I used a multi-meter to measure the voltage on the DTR line. When the adaptor has power and is enumerated, the DTR line is high (5V). When minicom is connected, the DTR line goes low (0v). When minicom is disconnected, DTR remains low (0v).

Therefore, hardware flow control for receiving characters from the SC126 is not actually wired-up to be CTS-RTS (really RTR see RS-232 specification post 1998).

[skullandbones]

@wwarthen you said

Still confused with this. I'm not clear why the adaptor cannot be plugged in, enumerated, and minicom started long before ever plugging the adapter into the SC126.

It is a bit risky to dynamically connect the adaptor to the SC126 with live 5V present on the unprotected pins of the adaptor's 6 way male header. Meaning that if I slipped or pushed the adaptor into the wrong pins on the female header then I could damage the board. It is much safer to dynamically connect and disconnect the USB cable.

[skullandbones]

@wwarthen I did some tests using v3.4.0-dev.10 with SUPCTS being FALSE. As far as I can tell, this setting produces the same observations as v3.4.0-dev.9.

I also tried v3.4.0-dev.10 with SUPCTS being TRUE and observe a different pattern of garbled text. This time all the status LEDs including number 7 become illuminated.

If I start minicom quickly within the 3 second delay period, then the bootloader messages are shown OK.

If I take my time starting minicom (longer than 3 seconds) then I see some garbled characters.

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on May  6 2018, 07:48:54.
Port /dev/ttyUSB1, 21:32:59

Press CTRL-A Z for help on special keys

¥Ñåѽj½5Rjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjjj¤4
                                                                                                      +$&H

Pressing return causes all 8 status LEDs to turn off but no menu is shown. Pressing return again shows nothing. Pressing return shows

  I <u> [<c>] - Set Console Interface/Baud code
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  <u>[.<s>]   - Boot Disk Unit/Slice

Boot [H=Help]:

some of the textual output appears missing. Potentially, this is a transmitter defect.

Pressing return again

  L           - List ROM Applications
  D           - Device Inventory
  R           - Reboot System
  I <u> [<c>] - Set Console Interface/Baud code
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  <u>[.<s>]   - Boot Disk Unit/Slice

Boot [H=Help]: 

and this is the expected output.

So it seems that neither settings for SUPCTS gives me the same behaviour as per v3.4.0-dev.1. I guess I should recheck this version.

[wwarthen]

In the high level config file ("cfg_SCZ180.asm"), change:

DEFSERCFG .EQU SER_115200_8N1 | SER_RTS ; DEFAULT SERIAL LINE CONFIG (SEE STD.ASM)

to

DEFSERCFG .EQU SER_115200_8N1 ; DEFAULT SERIAL LINE CONFIG (SEE STD.ASM)

That is the one other thing that was changed when the CTS change was made.

Thanks,

Wayne

[wwarthen]

@wwarthen Looking in more detail to the connections on the USB to serial adaptor, I note that the DTR line (output) from the adaptor is connected to CTS (input) of the SC126 board. Therefore, RTS (output) from the adaptor is not connected.

I used a multi-meter to measure the voltage on the DTR line. When the adaptor has power and is enumerated, the DTR line is high (5V). When minicom is connected, the DTR line goes low (0v). When minicom is disconnected, DTR remains low (0v).

Therefore, hardware flow control for receiving characters from the SC126 is not actually wired-up to be CTS-RTS (really RTR see RS-232 specification post 1998).

The USB-to-Serial adapter you are using is not the one intended by Steve. Some substitute DTR for CTS (like yours). They are the ones primarily geared toward the Arduino which uses DTR as a reset. Ideally, you want one with real CTS like this:

https://ftdichip.com/products/ttl-232r-5v/

It may or may not actually affect your symptoms.

Thanks,

Wayne

[wwarthen]

It is a bit risky to dynamically connect the adaptor to the SC126 with live 5V present on the unprotected pins of the adaptor's 6 way male header. Meaning that if I slipped or pushed the adaptor into the wrong pins on the female header then I could damage the board. It is much safer to dynamically connect and disconnect the USB cable.

Fair enough. But the flip side of this is that you are not providing a stable serial interface to your SC126 at startup.

Thanks,

Wayne

[skullandbones]

@wwarthen here are my test results using v3.4.0-dev.1

If I connect the USB cable to the USB adaptor to power the SC126 board and wait more than 3 seconds and then start minicom, I get a blank screen because the bootloader is waiting at the menu prompt. Next I press the return key and as expected the menu is displayed.

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on May  6 2018, 07:48:54.
Port /dev/ttyUSB1, 17:00:38

Press CTRL-A Z for help on special keys

H

  L           - List ROM Applications
  D           - Device Inventory
  R           - Reboot System
  I <u> [<c>] - Set Console Interface/Baud code
  V [<n>]     - View/Set HBIOS Diagnostic Verbosity
  <u>[.<s>]   - Boot Disk Unit/Slice

Boot [H=Help]: 

It seems that I am unable to generate any garbled characters with v3.4.0-dev.1

If I am quick enough and start minicom under 3 seconds then I am able to capture the bootloader messages,

Welcome to minicom 2.7.1

OPTIONS: I18n 
Compiled on May  6 2018, 07:48:54.
Port /dev/ttyUSB1, 17:13:20

Press CTRL-A Z for help on special keys

RomWBW HBIOS v3.4.0-dev.1, 2023-10-17

Small Computer SC126 [SCZ180_sc126] Z8S180-N @ 18.432MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2, Z180 MMU
512KB ROM, 512KB RAM
ROM VERIFY: 00 00 00 00 PASS

AY: MODE=RCZ180 IO=0x68 NOT PRESENT
ASCI0: IO=0xC0 ASCI W/BRG MODE=115200,8,N,1
ASCI1: IO=0xC1 ASCI W/BRG MODE=115200,8,N,1
DSRTC: MODE=STD IO=0x0C Tue 2023-10-17 16:12:35 CHARGE=OFF
MD: UNITS=2 ROMDISK=384KB RAMDISK=352KB
FD: MODE=RCWDC IO=0x50 NOT PRESENT
IDE: IO=0x10 MODE=RC
IDE0: NO MEDIA
IDE1: NO MEDIA
PPIDE: IO=0x20 PPI NOT PRESENT
SD: MODE=SC OPR=0x0C CNTR=0xCA TRDR=0xCB DEVICES=1
SD0: SDHC NAME=SL16G BLOCKS=0x01DACC00 SIZE=15193MB
FP: IO=0x00 NOT PRESENT

Unit        Device      Type              Capacity/Mode
----------  ----------  ----------------  --------------------
Char 0      ASCI0:      RS-232            115200,8,N,1
Char 1      ASCI1:      RS-232            115200,8,N,1
Disk 0      MD0:        RAM Disk          352KB,LBA
Disk 1      MD1:        ROM Disk          384KB,LBA
Disk 2      IDE0:       Hard Disk         --
Disk 3      IDE1:       Hard Disk         --
Disk 4      SD0:        SD Card           15193MB,LBA

Small Computer SC126 [SCZ180_sc126] Boot Loader

Boot [H=Help]: 

Hence, I reported a regression because there is a change in behaviour with v3.4.0-dev.9.

I will now try to bisect between v3.4.0-dev.1 and v3.4.0-dev.9 to confirm which tag first shows the change in behaviour,

I note your previous comment about a RTS change.

Thanks,

Dean

[skullandbones]

@wwarthen I can confirm that v3.4.0-dev.5 is OK with no garbled text and v3.4.0-dev.6 shows a change in behaviour with garbled text.

I noted that there are 2 commits between v3.4.0-dev.5 and v3.4.0-dev.6: 872d51e9 Detect CTS Stall b41f189a Miscellaneous

I will now build 'b41f189a' which should have no garbled text leaving '872d51e9 Detect CTS Stall' as the site of the change of behaviour (as expected).

I have confirmed that 'b41f189a' does not generate garbled text.

Regards, Dean

[skullandbones]

@wwarthen you said

Fair enough. But the flip side of this is that you are not providing a stable serial interface to your SC126 at startup.

I agree that there is some strangeness that causes garbled text and potentially the adaptor is mishaving. However, my testing shows that no garbled text appears prior to v3.4.0-dev.6. Therefore, there is some trigger for the garbled text that depends on RomWBW.

[skullandbones]

@wwarthen The USB to serial adaptor came with the SC126 kit.

Dean

[wwarthen]

@wwarthen The USB to serial adaptor came with the SC126 kit.

Odd. That is not what Steve has provided in the past and it doesn't match the schematic. I will follow up with him to understand what his intentions are.

[wwarthen]

I will now build 'b41f189a' which should have no garbled text leaving '872d51e9 Detect CTS Stall' as the site of the change of behaviour (as expected).

Will be interesting to hear the results. I suspect you will find that the change in DEFSERCFG turns out to be the critical difference.

Thanks,

Wayne

[skullandbones]

@wwarthen in reply to your comment about the USB to serial adaptor.

I purchased the SC126 kit in May 2021.

I found this URL in my order E-mail: https://www.tindie.com/products/tindiescx/components-for-rcbus-rc2014-and-z50bus/#

There is a picture of the USB to serial adaptor on that webpage that looks like the one I have. I think you can see DTR printed on the PCB near the last pin (bottom left pin in the picture).

[skullandbones]

@wwarthen you said

Will be interesting to hear the results. I suspect you will find that the change in DEFSERCFG turns out to be the critical difference.

I took v3.4.0-dev.6 as the baseline and added my own commit on top to remove SER_RTS from DEFSERCFG as follows: In Source/HBIOS/cfg_scz180.asm

-DEFSERCFG      .EQU    SER_115200_8N1 | SER_RTS        ; DEFAULT SERIAL LINE CONFIG (SEE STD.ASM)
+DEFSERCFG      .EQU    SER_115200_8N1  ; DEFAULT SERIAL LINE CONFIG (SEE STD.ASM)

and no garbled characters are observed.

So you are right that adding SER_RTS to DEFSERCFG was the critical change.

Now I need to understand what SER_RTS means.

As previously stated, RTS logically means RTR (Ready To Receive) as per the RS-232 specifications post 1998 and in the European ITU-T V.24 and V.28 circuit specifications.

RTS (Request To Send) is for half-duplex flow control on a single serial line using a 3-way handshake (obsolete). RTR (Ready To Receive) is for full-duplex flow control on a single serial line using a single handshake (modern circa 1990s)

Unfortunately, the PC manufacturers in the early 1990s rolled-out the 9 pin sub-D connector for RS-232 before the standards body had codified the full-duplex handshake protocol. Sadly, the RTS legend never got amended to be RTR.

The term RTS (Ready To Send) is talking about its transmitter and not its receiver (assuming DTE definitions). It causes loads of confusion. This is because the scenario for RTS (Ready To Send) is half-duplex flow control which we no longer use.

Engineers fail to read specifications and the myth of RTS lives on in modern IP block chip designs and UART drivers.

Similarly, Baud Rate is a marketing term for modem salespeople. In the early days, synchronous modems were used. Baud is the symbols per second rate of the transmission line associated with the modulation scheme. So Baud Rate is the required clock frequency (bps) of the serial data to be fed into the modem to get the desired Baud on the transmission line.

It amuses me when people say "9600 Baud" instead of "9600 bps" because a lot of early documents referred to "9600 Baud".

But hey. I guess it is like calling a SD card, a hard disk. ;-)

Thanks,

Dean

[wwarthen]

I agree that the terminology and standards are a nightmare. I fully comprehend that RTS in this context is really RTR. I'm also aware of the baud vs. bps issue. I will still use the RTS and baud terms for now because that is simply what everyone else is using and I will confuse others if I switch at this point. 😀

With respect to the SER_RTS config value, let me clarify what is actually happening.

First, understand that the SER_RTS setting is actually intended to mean enable RTS and CTS flow control. I know it doesn't say that, but that is the intent. Typically, both things would be enabled at the same time on a serial port. Consider SER_RTS to be a shortened form of SER_RTSCTS (maybe I will go ahead and change the constant).

The ASCI serial ports in RomWBW are interrupt driven. As a result, they always do RTS flow control. This is true no matter what DEFSERCFG says. This is because there would be extra overhead in the interrupt handler to constantly check whether to update the RTS signal. Since RTS is an outbound signal, the other end is free to respect it or ignore it, the RomWBW driver just handles the RTS outbound signal as though it is enabled all the time. So, it is going to be enabled for ASCI0 all the time. ASCI1 has no RTS/CTS signals (deficiency of the Z180 chip), but you are using ASCI0, so no matter.

So, what exactly is happening when SER_RTS is part of DEFSERCFG? For ASCI, in reality it just enables CTS flow control. As you probably know CTS flow control is how the remote end (non-SC126) paces incoming data.

Applied to your situation, we now know that when CTS flow control is active, you are getting garbage characters. When you removed CTS flow control, the garbage characters are gone. The whole situation is made more convoluted by the fact that the USB adapter is actually sending DTR to the pin that is expected to be CTS by RomWBW. The garbage characters are clearly those characters sent from SC126 to the host in the time window after Linux recognizes the serial port and the time that minicom starts up. However, I am still not sure why this change in CTS behavior is resulting in the presence or lack of the garbage characters.

I have exchanged emails with Steve and he has acknowledged that the adapter is probably sending DTR instead of CTS. I still think this is a different adapter than he was originally distributing, but maybe my memory is bad. In reality, we know that the adapter is basically working fine with CTS flow control enabled because there is no issue other than your specific startup sequence. This means that the Linux host must be holding DTR asserted which then becomes CTS asserted to the SC126 and all is well.

Anyway, this does not really explain why you are getting garbage characters. For the time being, you can certainly just change DEFSERCFG to remove SER_RTS. I remain reluctant to remove SER_RTS from the default configuration. The reason is that many users enjoy using old CRT terminals. Those terminals cannot accept 115,200 baud without pacing of the input data which is achieved by CTS flow control. I will think about this a bit more.

Thanks,

Wayne

[wwarthen]

Hi @skullandbones,

I was finally able to find a combination of stuff that allowed me to recreate your symptoms. I was able to see exactly the same garbage characters that you report. Being able to really see what was happening, I was able to deduce what is actually going on.

Let's start with the situation where CTS flow control is enabled in RomWBW. When you plug in the adapter, CTS (and DTR) are not asserted, so RomWBW waits to send any characters. When you start minicom, it first asserts CTS (and DTR), but has not yet set the baud rate. RomWBW starts sending data which is interpreted as garbage because the baud rate is not yet initialized. Once the baud rate is initialized, operation is normal.

As you have pointed out, if you are able to get minicom started before RomWBW starts sending characters, then all is well because the baud rate is initialized before RomWBW sends any characters.

Now, let's examine the situation where CTS flow control is not enabled in RomWBW. In this scenario, RomWBW will not wait for CTS (or DTR) to start sending characters. The garbage characters wind up being discarded because they are sent before minicom is started. Once minicom is started, all is well, but the boot messages were already discarded.

This explains why the SER_RTS setting is affecting whether you see the garbage characters.

Thanks,

Wayne

[skullandbones]

@wwarthen thanks for your explanations.

I had some confusion reading your explanations because of a lack of context. There are 4 hardware flow control pins namely, the Z80 UART has RTS and CTS pins and the remote end (adaptor) also has RTS (wired as DTR) and CTS pins. So I became confused to which RTS pin and which CTS pin was being described. Also, the transmission direction was unclear.

You said

I will still use the RTS and baud terms for now because that is simply what everyone else is using and I will confuse others if I switch at this point.

I suspect that is what people said 25 years ago and is why the myths of RTS and Baud Rate persist to this day. Once something is named imprecisely and is in common usage then it hard to correct it. All you can do is add some clarity to the terms such as having a table of terms with usage notes.

For example, avoid using the term "Request To Send" as that is a major source of confusion. I agree with using the term RTS because that is the legend on the pin and written in the Z80 UART documents. It is just that logic of the handshake is RTR -> CTS (both DTE).

First, understand that the SER_RTS setting is actually intended to mean enable RTS and CTS flow control. I know it doesn't say that, but that is the intent. Typically, both things would be enabled at the same time on a serial port.

This confused me. The transmitter can have hardware flow control and/or the receiver can have hardware flow control. Saying RTS and CTS is ambiguous to the transmission direction. It is clearer to say TX (output) and RX (input) hardware flow control.

Consider SER_RTS to be a shortened form of SER_RTSCTS (maybe I will go ahead and change the constant).

SER_RTS was definitely confusing me because I expected it to mean enable RTS such as RTS is always asserted. Perhaps use SER_HWFLW ? Otherwise, I vote for SER_RTSCTS.

I have a doubt, is SER_RTS referring to both the TX and RX lines ? eg. full duplex flow control ? Or is SER_RTS only for TX (output) or RX (input) hardware flow control ?

The ASCI serial ports in RomWBW are interrupt driven. As a result, they always do RTS flow control. This is true no matter what DEFSERCFG says. This is because there would be extra overhead in the interrupt handler to constantly check whether to update the RTS signal. Since RTS is an outbound signal, the other end is free to respect it or ignore it, the RomWBW driver just handles the RTS outbound signal as though it is enabled all the time.

I think that this paragraph is talking about the RX (input) interrupt handling. Therefore, the RTS pin (output) of the Z80 UART is being actively controlled by RX interrupt routine. DEFSERCFG does not disable this RX hardware flow control signal.

So, what exactly is happening when SER_RTS is part of DEFSERCFG? For ASCI, in reality it just enables CTS flow control. As you probably know CTS flow control is how the remote end (non-SC126) paces incoming data.

Let me try to break this down as some context is not clear with respect to transmission direction. I think you are referring to the CTS pin on the Z80 UART which is an input. Here CTS is controlling the TX (output) of the Z80 UART. The remote end drives the Z80 UART's CTS pin to pace the rate at which the remote end receives data. I agree.

The whole situation is made more convoluted by the fact that the USB adapter is actually sending DTR to the pin that is expected to be CTS by RomWBW.

I think you mean RTS aka RTR from the remote end here and not CTS. Meaning expected RTS ->CTS but DTR->CTS was wired-up.

I have exchanged emails with Steve and he has acknowledged that the adapter is probably sending DTR instead of CTS.

I think you mean RTS and not CTS on the adaptor.

Let's start with the situation where CTS flow control is enabled in RomWBW. When you plug in the adapter, CTS (and DTR) are not asserted, so RomWBW waits to send any characters. When you start minicom, it first asserts CTS (and DTR), but has not yet set the baud rate. RomWBW starts sending data which is interpreted as garbage because the baud rate is not yet initialized. Once the baud rate is initialized, operation is normal.

An alternative explanation could be that there is a RX framing error due to the synchronous bit stream of the boot messages. Such as the Z80 started transmitting before the adaptor was fully configured causing a character's start bit to be missed. This could cause the adaptor to incorrectly frame lock to the bit stream.

Consider that the adaptor's DTR->CTS on the Z80 UART changes state which is the trigger for the Z80 UART to start transmitting. Meanwhile, minicom is busy configuring the adaptor. I think that the configuration time of the adaptor is much shorter than the total transmission time for the boot messages. However, Minicom can get confused when receiving garbled characters and malfunction.

I agree that the Baud Rate mismatch sounds the most plausible explanation but I have a doubt that a framing locking error could also generate similar symptoms.

I am thinking of setting-up a break out of the serial connections on a breadboard and connecting my oscilloscope to see the relative timing. Potentially I could hook up a second UART to sniff the transmissions.

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

Sorry for causing confusion. With respect to my use of the terms RX, TX, RTS, CTS, I will be referring to the SC126 side of the connection. This is consistent with the UART pin labels, SC126 schematic, and SC126 interface pin labels.

SC126           Adapter
-------         --------
RX      <--     TX
TX      -->     RX
RTS     -->     CTS
CTS     <--     DTR

I appreciate your thoughts about the terminology, but, right or wrong, I will continue to use the "old" terms.

First, understand that the SER_RTS setting is actually intended to mean enable RTS and CTS flow control. I know it doesn't say that, but that is the intent. Typically, both things would be enabled at the same time on a serial port.

This confused me. The transmitter can have hardware flow control and/or the receiver can have hardware flow control. Saying RTS and CTS is ambiguous to the transmission direction. It is clearer to say TX (output) and RX (input) hardware flow control.

In my comments, I use these meanings (relative to the SC126) RX = SC126 inbound data TX = SC126 outbound data RTS = SC126 outbound signal used for RX (input) flow control CTS = SC126 inbound signal used for TX (output) flow control

First, understand that the SER_RTS setting is actually intended to mean enable RTS and CTS flow control. I know it doesn't say that, but that is the intent. Typically, both things would be enabled at the same time on a serial port.

This confused me. The transmitter can have hardware flow control and/or the receiver can have hardware flow control. Saying RTS and CTS is ambiguous to the transmission direction. It is clearer to say TX (output) and RX (input) hardware flow control.

I hope my description of the signals as I am using them clarifies this.

Consider SER_RTS to be a shortened form of SER_RTSCTS (maybe I will go ahead and change the constant).

SER_RTS was definitely confusing me because I expected it to mean enable RTS such as RTS is always asserted. Perhaps use SER_HWFLW ? Otherwise, I vote for SER_RTSCTS.

Agreed.

I have a doubt, is SER_RTS referring to both the TX and RX lines ? eg. full duplex flow control ? Or is SER_RTS only for TX (output) or RX (input) hardware flow control ?

RomWBW uses the equate SER_RTS to mean the combination of RTS/CTS hardware flow control. Due to various issues, the implementation of the equate in any particular driver may or may not be this full combination of flow control. Think of SER_RTS to mean a stated desire to use or not use RTS/CTS flow control to the extent possible within the driver.

The ASCI serial ports in RomWBW are interrupt driven. As a result, they always do RTS flow control. This is true no matter what DEFSERCFG says. This is because there would be extra overhead in the interrupt handler to constantly check whether to update the RTS signal. Since RTS is an outbound signal, the other end is free to respect it or ignore it, the RomWBW driver just handles the RTS outbound signal as though it is enabled all the time.

I think that this paragraph is talking about the RX (input) interrupt handling. Therefore, the RTS pin (output) of the Z80 UART is being actively controlled by RX interrupt routine. DEFSERCFG does not disable this RX hardware flow control signal.

Exactly right.

So, what exactly is happening when SER_RTS is part of DEFSERCFG? For ASCI, in reality it just enables CTS flow control. As you probably know CTS flow control is how the remote end (non-SC126) paces incoming data.

Let me try to break this down as some context is not clear with respect to transmission direction. I think you are referring to the CTS pin on the Z80 UART which is an input. Here CTS is controlling the TX (output) of the Z80 UART. The remote end drives the Z80 UART's CTS pin to pace the rate at which the remote end receives data. I agree.

Exactly right.

The whole situation is made more convoluted by the fact that the USB adapter is actually sending DTR to the pin that is expected to be CTS by RomWBW.

I think you mean RTS aka RTR from the remote end here and not CTS. Meaning expected RTS ->CTS but DTR->CTS was wired-up.

Yes.

I have exchanged emails with Steve and he has acknowledged that the adapter is probably sending DTR instead of CTS.

I think you mean RTS and not CTS on the adaptor.

Yes, sorry.

Let's start with the situation where CTS flow control is enabled in RomWBW. When you plug in the adapter, CTS (and DTR) are not asserted, so RomWBW waits to send any characters. When you start minicom, it first asserts CTS (and DTR), but has not yet set the baud rate. RomWBW starts sending data which is interpreted as garbage because the baud rate is not yet initialized. Once the baud rate is initialized, operation is normal.

An alternative explanation could be that there is a RX framing error due to the synchronous bit stream of the boot messages. Such as the Z80 started transmitting before the adaptor was fully configured causing a character's start bit to be missed. This could cause the adaptor to incorrectly frame lock to the bit stream.

Consider that the adaptor's DTR->CTS on the Z80 UART changes state which is the trigger for the Z80 UART to start transmitting. Meanwhile, minicom is busy configuring the adaptor. I think that the configuration time of the adaptor is much shorter than the total transmission time for the boot messages. However, Minicom can get confused when receiving garbled characters and malfunction.

I agree that the Baud Rate mismatch sounds the most plausible explanation but I have a doubt that a framing locking error could also generate similar symptoms.

Right, I can't prove it is baud rate vs. framing errors vs. adapter config time window.

I am thinking of setting-up a break out of the serial connections on a breadboard and connecting my oscilloscope to see the relative timing. Potentially I could hook up a second UART to sniff the transmissions.

I have already used my scope to confirm that the SC126 side of the conversation is fine. Specifically, the SC126 waits for CTS, then starts sending boot messages at 115200 baud. It looks completely clean on my scope. The problem is how the adapter is "seeing" the data stream.

I just ran an interesting experiment. I noticed that Linux uses 9600 baud as the default for a serial port. I reconfigured my SC126 to startup at 9600 baud. I also setup a config file for minicom so it could be started at 9600 baud. Doing these things, I am now getting a perfectly clean startup -- no garbage characters and no lost characters at all. I would claim this confirms that the original problem is baud rate mismatch during minicom initial startup. Essentially, when the port is opened by Linux, it is initialized to 9600 baud. That is what causes the baud rate mismatch window. You probably don't want to have your SC126 configured for 9600 baud, but I think this experiment helps isolate the garbage problem.

One more thing. I realized that there is another way to power on the SC126. Remove the 2 pin connector that enables power to the SC126 the serial adapter. You can then plug in everything all the way through to the Linux box and start minicom. To actually power on the SC126, just put the jumper in place. You could even wire up a small toggle switch to the jumper pins which would make it very easy and safe to power up. This would give you a very nice clean startup.

Thanks,

Wayne

[skullandbones]

@wwarthen thanks for your reply.

One more thing. I realized that there is another way to power on the SC126. Remove the 2 pin connector that enables power to the SC126 the serial adapter. You can then plug in everything all the way through to the Linux box and start minicom. To actually power on the SC126, just put the jumper in place. You could even wire up a small toggle switch to the jumper pins which would make it very easy and safe to power up. This would give you a very nice clean startup.

Yep, I had already realised this. A toggle switch would be nice ;)

Would it be possible to implement 2 stop bits on the Z80 UART ? This would increase the chances of forcing correct framing. I mean this more as a test than a fix.

My doubt is that the Baud Rate maybe becomes set correctly in the adaptor during the transmission of the boot messages. Meaning that the garbled text should become good as long as correct framing is synced. Of course minicom may have malfunctioned by that point so hiding the good text.

I do agree with your 9600 bps testing. 9600 bps was very commonly used with Linux based target boards which is likely to be when the Linux USB serial drivers were written. I could try to look at the kernel drivers to see the setup.

I would of hoped that the DTR and RTS lines on the adaptor would have been the last thing to be asserted after the Baud Rate had been set.

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

Would it be possible to implement 2 stop bits on the Z80 UART ? This would increase the chances of forcing correct framing. I mean this more as a test than a fix.

Sure. It is just a config change. Refer to std.asm for values. I think you can do this yourself.

My doubt is that the Baud Rate maybe becomes set correctly in the adaptor during the transmission of the boot messages. Meaning that the garbled text should become good as long as correct framing is synced. Of course minicom may have malfunctioned by that point so hiding the good text.

I do agree with your 9600 bps testing. 9600 bps was very commonly used with Linux based target boards which is likely to be when the Linux USB serial drivers were written. I could try to look at the kernel drivers to see the setup.

You can see that it is 9600 baud using stty. Unfortunately, you cannot change it before the adapter is inserted in the Linux system.

I would of hoped that the DTR and RTS lines on the adaptor would have been the last thing to be asserted after the Baud Rate had been set.

Right. I don't think there is much you can do.

I think this discussion has pretty well exhausted the original issue. I'm convinced there is no bug in the RomWBW serial driver. Yes, there was a change in the default behavior, but it is an intended change and can be overridden if desired.

Are we OK to close this issue?

Thanks,

Wayne

[skullandbones]

@wwarthen using 2 stop bits fixed it.

Here is an example of what is seen in minicom when 2 stop bits are used.

¶Ùٻ.S, 2023-10-19

Small Computer SC126 [SCZ180_sc126] Z8S180-N @ 18.432MHz IO=0xC0
0 MEM W/S, 2 I/O W/S, INT MODE 2, Z180 MMU
512KB ROM, 512KB RAM
ROM VERIFY: 00 00 00 00 PASS

I repeated the test several times and there is some variability in the number of garbled characters seen and the start of the good characters being displayed.

In the example, the missing characters are

RomWBW HBIOS v3.4.0-dev.

and this represents the length of time that the mismatch in Baud Rate takes place before the correct Baud Rate is selected in the adaptor.

Using 2 stop bits increases the selectivity in the RX frame matching algorithm in the adaptor resulting in more bad characters being rejected than with 1 stop bit being used. In turn, this prevents minicom from processing the garbled characters that triggers some reaction resulting in a malfunction of minicom.

It might be that minicom has some protocol handlers that are monitoring the character stream and get erroneously triggered by the garbled text. These protocols might be kermit or zmodem or some such. Perhaps these protocol handlers can be disabled in minicom which might also provide a solution with 1 stop bit.

Back to using 1 stop bit as per v3.4.0-dev.6

I wired a USB to serial adaptor from my RC2014 Z80 kit in parallel with the rogue adaptor of the SC126 kit. This allowed me to sniff the TX output of the SC126 UART during my testing with the rogue adaptor. The sniffing revealed that minicom was sending characters

Boot [H=Help]: Minicom2.7.1Mini

so here is an example text being echoed back at the prompt. This "Minicom2.7.1Mini` text is a bit variable and changes a bit in each test run but it is clearly minicom sending a string of its name.

With the rogue adaptor generating garbled text, this "Minicom2.7.1Mini` text is hidden on the minicom display. Subsequently, pressing the return key puts the system into Monitor Mode because the "M" of "Minicom" is processed. That explains how Monitor Mode gets selected.

The USB to serial adaptor from my RC2014 Z80 kit is a different design to the rogue adaptor. The RC2014 adaptor has RTS instead of DTR and uses a different USB serial port protocol. However, the RC2014 adaptor appeared to be struggling to provide 5V because the board reset after the end of the boot messages had been output. Eventually, I managed to get the system to be stable to run some tests. The RC2014 adaptor did not deassert RTS (always low) so the SC126 did not wait to transmit. RTS was low even when minicom was not connected.

I hope that helps ?

Thanks,

Dean

[wwarthen]

Hi @skullandbones,

Interesting information. Nothing terribly surprising, but good to be aware of.

I am going to go ahead and close this issue since it seems clear that RomWBW is operating as designed.

Thanks,

Wayne