[SOLVED] Z80 SBC - occasionally corrupted characters in serial communication - Page 1
Forum section: electronics / projects

author: Maf
author_rank: Contributor
timestamp: August 21, 2016, 03:01:39 pm
content: Hi everyone, I seem to have a problem similar to the one described inhttps://www.eevblog.com/forum/beginners/16550-uart/. I have already lost last three days trying to solve it, so I think it's time you ask you for help.I am working currently on a Z80 SBC. Everything seems to work, I have managed to run 8k BASIC on it, but I can't get the serial communication to work properly. Every now and then my I (my terminal) receive not the character that I typed.So I wrote a simple echo program to analyse the issue further. Using an oscilloscope I found out that the data corruption happens either when the UART is receiving the bit stream from MAX232, or when it puts the received character on the databus (well, or when the CPU is strobing the databus). I also displayed the character on a dual hex LED display and it was always the upper nibble that was corrupted.Transmission (from SBC to the terminal) works always correctly.The data path consists of Z80A, Z80DART and MAX232. On the other side is a FTDI serial-to-usb converter and a Linux laptop.The Z80DART gets its baud rate from a Z80CTC. I measured it with oscilloscope and it's as expected.Things that I've already tried:- different CLKs: 1 MHz, 4 MHz- different baud rates: 300, 2400, 9600- using CMOS instead of NMOS CPU- using Z80SIO instead of Z80DART- using 8N2 encoding instead of 8N1None of it helped.Do you guys have any ideas what might be the issue here?

author: SeanB
author_rank: Super Contributor
timestamp: August 21, 2016, 05:49:02 pm
content: Try adding some decoupling caps to the board, and change the clock to 4.096MHz, which gives a better match for the BAUD rate generation.Decoupling capacitors can be 220n disc ceramic units with long leads, plugged directly into the breadboard next to the power and ground pins of all the IC's, and a 100uF 16V regular electrolytic on the power input side and output of that 7805 regulator. That at least will improve supply decoupling slightly, and the clock speed will get the decode timing into better framing in the UART.

author: woodchips
author_rank: Frequent Contributor
timestamp: August 21, 2016, 06:39:29 pm
content: Use two stop bits in the RS232, getting corruption from a slippage of the baud rate between Tx and Rx.

author: Maf
author_rank: Contributor
timestamp: August 21, 2016, 08:08:52 pm
content: Quote from: SeanB on August 21, 2016, 05:49:02 pmWhy should it matter if the baud rate is generated correctly?Quote from: SeanB on August 21, 2016, 05:49:02 pmI use those already. There is a electrolytic 330nf on the input and a ceramic 100nF on the output of the 7805. Plus a some ceramic 1uF here and there near the ICs.

author: Maf
author_rank: Contributor
timestamp: August 21, 2016, 08:48:45 pm
content: Quote from: woodchips on August 21, 2016, 06:39:29 pmI tried it out but this didn't help.

author: Maf
author_rank: Contributor
timestamp: August 22, 2016, 05:16:15 am
content: I have found the problem. I used 'U' character in the echo program and monitored RxDA (receiver data) and RxCA (receiver clock) signals with oscilloscope. It looks like the baud rate of the RxCA clock is _slightly_ faster that rate of the incoming data. So, in those rare cases, b0 is sampled (with the rising edge of the RxCA) shortly after it was set (which is OK), but all next bits are sampled a little bit faster than expected, so that b6 is sampled instead of b7 (screenshots attached).Is there anything I can do against it?I double checked - the baud rate is clean 2.4 kHz.

author: woodchips
author_rank: Frequent Contributor
timestamp: August 22, 2016, 05:48:48 pm
content: The whole idea of asynchronous comms is that the receiver resyncs on every character. Normally the stop bit is only half used, samples in the centre of each bit, but if the two baud rate frequencies are sufficiently far apart then after a few continuous characters this fails. Hence the suggestion to use two stop bits, has to be a serious difference in Tx baud and Rx baud rates for that to fail.This was a common problem with the old computers, Apple 2 springs to mind, where the baud rate clock used the same oscillator as the CPU. This has caused weeks of torn hair before the problem was found. Also ensure that there really is a solid 0V connection between the two boards, another torn hair failing! Check which pins you are using in the connector, pin 7 is 0V, not pin 1 which is GND.Measure using a counter timer the Tx and Rx baud rates, then double check that the comms chips really are using the X16 divider clock for the baud rate, then do the maths.

author: SeanB
author_rank: Super Contributor
timestamp: August 22, 2016, 06:06:53 pm
content: If you are using a USB to serial converter they often are slightly out with the BAUD rate clocks they use, as they almost always make it from the 12MHz USB clock, which is internally multiplied in the converter to a 48MHz clock using a PLL. This then has jitter on it, and also will drift with temperature and USB supply voltage slightly.The clock is divided down to make a close but not exact BAUD clock ,and this error, along with the drift, will give a problem with corruption of the recieved and transmitted data as the clock gets further out of sync with each frame. Only cure, aside from finding a BAUD rate which is a correct one on the PC side ( there will be one that is almost perfect somewhere in the settings), is to change the receive clock to put it at a better place in the sample window for each byte.

author: PA0PBZ
author_rank: Super Contributor
timestamp: August 22, 2016, 06:32:38 pm
content: I have no idea how the DART can even work with RxCA on x 1, it has no way of synchronizing to the incoming async data.I'd try to run it at least with a x 16 clock and see if that improves things.

author: Maf
author_rank: Contributor
timestamp: August 22, 2016, 07:58:49 pm
content: @woodchips, @PA0PBZ: Yep... using 1x clock on the RxC was cause of the issue. Changing to 16x fixed the problemThanks.

author: basinstreetdesign
author_rank: Frequent Contributor
timestamp: August 23, 2016, 02:51:30 am
content: I had this problem in 1981 once. Almost exactly the same cause.Yes the whole idea of serial ASCII is that the receiver re-sync with the falling edge of the first bit of every character., However if you are sending a string of characters and the receivers' baud rate is marginally slower than the transmit rate, then the receiver will eventually run out of time and corrupt a character. Even 0.0001% too slow will do it if the string is long enough. The cure for that is to either slow down the transmitter by .1% , speed up the receiver by the same or insert a bit of dead time between characters somehow.