topic Re: MPC8xx HDLC Postambule in PowerQUICC Processors

MPC8xx HDLC Postambule

sebastienblavie — Wed, 13 Jan 2016 10:51:58 GMT

Hi,

I try to dialog 2 boards through HDLC FM0 => MPC885 on both side.

(configuration , preambule 8 bits 0xFF, Glitch=OFF, Transparent mode=OFF, CRC=16 bits, TX=16 bytes, RX=32 bytes, X21=OFF, TBRTSM=0)

when i set the field TEND of GSMR_L to 1, ie. TXD is always encoded, even when idles are sent => no problem.

But when i set the field TEND to 0, ie. TXD is encoded only when data is sent , on Rx board side the MPC885 log the error AB and skip the check of CRC on each received frame.

The datasheet $23.3 says

Note that an SCC in HDLC mode, or any other synchronous mode, must receive a minimum of eight

clocks after the last bit arrives to account for Rx FIFO delay.

So i think when the TEND field is set to 0, 8 clock are automaticly sent but not with TEND set to 0 which is my problem.

To send a second closing flag or a postambule ( $23.3 adding 8 clock at the end) , i set the field NOF of the PSMR to 2.

Note NOF : Number of flags. Minimum number of flags between or before frames.

But in this case (NOF ==2) only the opening flagis impact (at least 2 opening flag) never for the closing flag (always 1).

Somebody can help me to add the 8 clock at the end of closing flag ?

thanks

Re: MPC8xx HDLC Postambule

r8070z — Mon, 18 Jan 2016 20:11:32 GMT

Have a great day,

I am not sure what "X21=OFF, TBRTSM=0" mean. I guess you set GSMR_H[RTSM] = 0. If so than the manual clearly state that if you set GSMR_L[TEND] = 0 then after HDLC frame closing flag the TX signal is driven high (or by other word idle is not FM0 encoded).

I do not think your problem is related to the 8 clocks required to push out the last frame byte. They mean that the last byte will be just delayed if there is not 8 clocks after. I.e. when the next frame begins it pushes-out the last byte of the previous without any error.

I believe "error AB" means ABort sequence detected (i.e. seven or more consecutive ones are received while receiving a frame) when the channel closes the buffer and sets RxBD[AB]. The receiver then enters hunt mode.

I may suppose that while TX-to-Rx line is high after closing flag the RX DPLL continues to operate and restores it as abort sequence. I recommend to set RTSM or TEND. May be GSMR_L[TSNC] can help - try to decrease the amount of time the internal sense signal stays active after the last transition on the RXDx pin.

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

Re: MPC8xx HDLC Postambule

sebastienblavie — Mon, 18 Jan 2016 21:06:37 GMT

Hi,

Thanks for the reply.

Yes i set GMSR_H to 0 so GSMR_H[RTSM] =0.

I am not sure but in HDLC mpde i think the GSMR_H[RTSM] and GSMR_L[TEND] are the same, ie. idle mode == GSMR_H[RTSM] or GSMR_L[TEND].

Because i try to set RTSM and reset TEND or reset RTSM and set TEND => idle is always encoded,

I try to set the GSMR_L[TSNC] to . 01 14- or 6.5-bit times as determined by RDCR and all other values, GSMR_L[RDCR] is set 16x but there is not difference error AB still present.

This configuration comes from an old project, on this project on the second board the HDLC/FM0 is managed by an FPGA and not by the MPC885.

Message from first board (HDLC managed by MPC885 and ADA driver) to second board, no postambule.

Message from second board (HDLC manage by the FPGA) to first board, a postambule is present and no error AB.

FPGA's team has confirmed to me that a postambule is added but no feedback why ?? maybe to fixe this pb ?

Sebastien.

Re: MPC8xx HDLC Postambule

r8070z — Tue, 19 Jan 2016 10:04:31 GMT

The DPLL is not documented in details so I wrote try to use TSNC if it can help. Yes I recommended to set RTSM or TEND because any of these settings will keep FM0 alive on the line. I think it reasonable to keep valid FM0 signal on line while receiver continue to expect FM0 signal otherwise it may get invalid values.