MC68302 / HDLC problem

[brudd]

We are using a Motorola MC68302 communications processor in slave mode in receive HDLC mode.
Unless we use the same system clock for both transmit and receive we get many message errors
in the receive (every 3 to 4 messages gives an rx error; usually Non Octet Aligned Frame
or Rx Abort Sequence errors.

It seems we are missing something in the setup (or maybe the hardware) such that the transmit
and receive are not in sync. We have read the MC68302 user manual from cover to cover but
cannot see where we are going wrong.

Here is our setup.
==================

system clock = 19.6608MHz
Mode HDLC NRZI baud rate  = 19200

We are using 68302 processor running on system clock of 19.6608MHz. The channel 1
(SCC1) is configured as HDLC NRZI receive only and its baud rate is 19200. This is a
two wire RS485 serial link.
We than use another set of same hardware and configure the channel 2 (SCC2) as
HDLC NRZI transmit only which is also is a two wire RS485 serial link. When we connect
 these two hardware together we receive 15-20% Errors which we don't understand why?

When we use one set of hardware and configure 68302 channel1 as HDLC NRZI Rx, channel 2 as
HDLC NRZI Tx and loop back channel1 to channel2, we do not see any errors and
we get 100% successful transmission. bearing in mind that the loop back does include
RS485 driver circuitry for both channels.

When we then shared the system  clock between the two systems this also does not generates
any errors and  produces 100% successful results.

All the above tests seems to indicate that there is synchronisation issue
between two sets of hardware.
What we don't understand is, if both hardwares are running at same baud rate
why should there be a sync problem?
Is 68302 really so intolerant about its baud rate?

Register setup
==============
The SCM register setting we are using to configure 68302 as Rx

NOF3-NOF0  = 0000
C32 = 0
FSE = 0
RTE = 0
FLG = 0 we tried both options for
idling it does seem to make any different.
ENC = 1 NRZI

DIAG1 & 0 = 11 Software Control
ENR,ENT = 01 Rx
MODE = 00 HDLC

[abartky]

Just caught an error in my previous reply. I had one case where I said "DTE" when I should have said "DCE". Here is the corrected paragraph:

Interfaces such as RS-232, V.35, RS-449, etc. all had the concept of a master (Data Communincations Equipment (DCE)) and a slave (Data Terminal Equipment (DTE)) where the DCE sent both data and clock and was the master of the clocking speed, and for syncrhonous communications there was an actual clocking signal that transmitted the DCE's clock to the DTE and the DTE then used that clock to receive data from the DCE and also send data back to the DCE based on that clock. That way everybody was in sync.

abartky

[abartky]

brudd,

It's been a long time since I've worked on HDLC, but I believe I can at least describe what is going on and where you can look next in fixing your problem as previously in my career, I worked on HDLC and derivative protocols for many years.

You wrote:

  What we don't understand is, if both hardwares are running at same baud rate
  why should there be a sync problem?

  Is 68302 really so intolerant about its baud rate?

The main issue with running these older protocols is that they are truly "synchronous" protocols and if you don't get the timing 100% exact, you'll get problems such as aborts, overruns, crc errors etc. These devices and associated level 1 protocols assume the timing must be just about perfect and when the receiver receives data from another devices, it must be syncrhonized by a clock that is either on the wire itself or is recovered in some manner.

Interfaces such as RS-232, V.35, RS-449, etc. all had the concept of a master (Data Communincations Equipment (DCE)) and a slave (Data Terminal Equipment (DTE)) where the DTE sent both data and clock and was the master of the clocking speed, and for syncrhonous communications there was an actual clocking signal that transmitted the DCE's clock to the DTE and the DTE then used that clock to receive data from the DCE and also send data back to the DCE based on that clock. That way everybody was in sync.

For later protocols such as RS-485, they got rid of the clocking signal on the interface and instead required each device use its own interenal clock for transmit and the for receive recover the clock. The Non-Return to Zero Inverted (NRZI) method was chosen as it allowed a receiving device to recover the clock by looking at the bit transitions versus a reference speed on the receiving end. This became the model for almost all layer 1 protocols after that, including Ethernet.

The key for the 68302 (at least my reading of the user manual) is that it does not have the function internally to do recovered clock by itself (it only supports internal and external, but does not in itself do clock recovery). Here is a key excerpt from the manual:

ENC—Data Encoding Format

0 = Non-return to zero (NRZ). A one is a high level; a zero is a low level.
1 = Non-return to zero inverted (NRZI). A one is represented by no change in the level;
a zero is represented by a change in the level. The receiver decodes NRZI, but a
clock must be supplied. The transmitter encodes NRZI. During an idle condition,
with the FLG bit cleared, the line will be forced to a high state.

The key phrase above is "The receiver decodes NRZI, but a clock must be supplied" meaning that the 68302 doesn't itself support clock recovery, and therefore if the design requires it (such as for 2 wire RS-485) then you need to get the clock from the PHY and use that clock source as an "extenal clock" for receive data.

So assuming your design supports a PHY that can recover clock and generate a signal out of the PHY and that signal is also then wired to the 68302 SCC input for that port, then what you need to do is set the SCCs up so that they use an internal 19.2 clock for transmit and then use an external clock for receive where that external clock comes from the RS485 PHY. I have never personally worked with RS485 PHYs, but I'm also guessing that they either need to have a reference frequency given to them to assist in the clock recovery, so you may need to look exactly how the PHY does clock recovery and what its requirements are (I would even guess that perhaps the PHY could possibly drive both transmit and receive clocks, in which case you'd set up the SCCs to run external clock for both transmit and receive). Anyway you'll need to look at the manual for the PHY chip and also understand how the clock is controlled and connected between the PHY and the 68302.

The reason that your test worked when you looped back was that as the transmitter and receiver were truly running of the same clock, everything was synchronous and so it worked whereas when you hooked up two separate systems, the clock only being off by a tiny amount will cause the errors you are seeing.

Anyway, hopefully this should get you going in the right direction to fix your problem.

Best regards,

abartky