uPD72103A (HDLC)

When the pointer in the HDLC and the pointer controlled by the host CPU become misaligned even by a single transmission or reception, communication becomes impossible.
Is there a problem with the settings?

The problem does not lie with the settings, but with the pointer controlled by the CPU side.

There is an unclear point regarding the initial setting operation of the uPD72103A.
This IC has a loopback mode that supports external looping depending on the setting, but when I tried it, it did not appear to be working properly.

The only setting I made was to set LOOP of MDST of LCW to "11", but a loop signal is not transmitted from RxD to TxD.
Normal communication works and according to the information sent in response to MDAK of LSW, the value of LOOP is "11", so that I think the setting is recognized in the IC.
Both RxD and TxD are synchronized to the external input clock. Is there something else that should be done?

Have you issued the LOPN command?
Confirm the procedure for setting the loopback mode.
To set the loopback mode, the initialization processing done through system reset → MSET → MDST → LOPN → LOAK verification is required at the very least.

Also, is the LOAK parameter of MDST set to flag transmission from the local node?
Also, is TFIL set to flag transmission?
If LOAK = 0, set TFIL = 0.
If LOAK = 1, input a regular HDLC frame as the frame looped back to RxD, to set the LOAK state.

The MDST command is valid only in the line closed state. Although it can also be issued in the line open state, but normal operation cannot be guaranteed in this event. Please check these points.

Under what circumstances does a receive buffer overflow cause occur?
Is it when fetching to internal is performed?

When there is some vacancy in RBAFIFO (equivalent to 4 sides) from the receive buffer address table, it is filled up, but when short packages come in in succession from the remote station, receive processing may come in in succession before the internal F/W performs fill-in, and as a result, the internal RBAFIFO gets drained, making frame receiving impossible.

The countermeasure for this consists in refraining from issuing maintenance type commands for statistical data, etc., and try insofar as possible not to perform continuous reception of short frames.

I have the receive buffer count and the status report table count for the same number of sides, but why doesn't status overflow occur?
Statistical information read is also performed.

Error frame and the receive frame for which receive buffer overflow occurred does not by itself become a receive status report cause.
Therefore, status overflow does not occur because of these error receptions.

The following kinds of events occur in a package that contains the uPD72103A.
<Events>

Three types of signals -transmission signal size, short frame (7 or 8 bytes), long frame (60 bytes)- are output, but only long frames are counted.

On the receiving side (package that contains uPD72103A), all the frames are received but only long frames are counted.

When operation is performed using the above-listed conditions, status overflow is counted in the statistical information read response, regardless of whether the number of long frame signals matches.

Does reception of short frames easily become a status overflow cause?

The receive status overflow occurrence mechanism is described below.

Since, in this LSI, frames that exceed the ability to continuously process receive frame reports are discarded, the number of vacancies of the status table is checked in advance and the maximum value is 6 sides.
This vacancy check is performed as part of the main routine of the internal F/W, and if interrupt servicing for receive status, statistical information, etc., frequently comes in, there is the possibility that the number of vacancies is 0 prior to the start of this vacancy check.
Regarding the frame received when the number of vacancies has become 0, this is subject to status overflow counting.

By the way, in the regular usage method, this vacancy check is performed for up to 6 sides, but if bit 7 of LCW(4) of the MDST command is set to "1", the check of the number of vacant sides can be made a check of all the unused areas of the status table.
However, this mode is an unreleased mode that hardly has a track record of use.

Based on the above, even if there are 7 or more vacant sides in the status table, there is the possibility that status overflow may occur if 7 or more frames are continuously received.

Is RxD signal edge detection done using both the rising edge and the falling edge?

Yes, it is done using both edges.