uPD72107 (LAP-B)

The uPD72107 is used in the transparent mode (with FCS processing). How many bits consist a frame to cause "short frame reception" in "statistical information read response"?

In the transparent mode, short frames are not detected.

Even when the uPD72107 is used in the transparent mode, do the communication frames received by the uPD72107 consist only of the communication frames transmitted from the station specified by ADDRY (remote station address) of the "system initialization" command?

No. Address detection is not performed in the transparent mode.
Therefore, since this information is treated simply as data and is not perceived as an address, the next receive data after the first flag becomes not an address but the first receive data.

The User's Manual says that during transmission/reception with the uPD72107 in the transparent mode the uPD72107 locks up if the RxC clock is stopped immediately after the end of data reception.
If the uPD72107 actually locks up, what happens to the TxD and RxD logic in terms of hardware?

Since the RxD pin is an input pin, it has no relation with the logic

The internal CPU, which performs command and status processing, falls in an endless routine when the RxC input stops at a timing until RxC is input again, and no processing is possible during this interval.

Therefore, TxD continues to perform frame transmission as long as the transmit clock is input during frame transmission, and when frame transmission ends, the state changes to the idle transmission state (dependent on TFIL).

I read that the count target for the number of long frame receptions in the statistical information read status consists of "error check deletion frames."
Is my assumption that this applies only in the transparent mode correct?

Also, in the non-transparent mode, is an error check deletion frame is counted for the number of long frame receptions?

The "number of long frame receptions" is the number of reception of an error check deletion frame that has an I field longer than the receive buffer size.
An error check deletion frame is a received frame that has passed the error check at the remote station in the LAP-B mode, and has no relation to the transparent mode.

Therefore, error check deletion frames are not counted for the number of long frame receptions in the transparent mode.

It is prescribed that it takes at least 12.5T from the end of DMA transfer until the next DMA transfer request.
Under what conditions does it take 12.5T?

When continuous DMA transfer occurs, if the transfers are executed without placing a time interval between them, the effect on the higher host increases.

For this reason, the specifications state that an interval of at least 12.5T must be secured between DMA transfers.
Regarding DMA transfer, since command, status, and other transfers also occur asynchronously, the DMA transfer interval is not constant.

When multiple DMA transfers occur internally, there is the possibility that DMA transfers will occur continuously in the order of reception > transmission > command/status transfer.

Further, in the case of DMA transfer of transmit/receive data only, the occurrence timing of internal DMA request is uniquely determined, and the same timing therefore results.
In this sense, the communication speed is a determining factor as far as the transfer of transmit/receive data goes.

It is prescribed that it takes at least 12.5T from the 1st DREQ on until the next DREQ on, but the time interval never got shorter than approximately 22.5T even though I have observed the waveform for a long time.

Under the usage conditions with 3.3792 MHz clock inputs and a transfer rate of 9,600 bps, the cycle for transferring 1 block of transmit/receive data takes 6.6 ms (= 1/9600 * 8 bits * 8 bytes), resulting in 22,302 clocks.

Even assuming that transmit and receive data transfer is alternately input in full duplex, logic-wise, the cycle is then cut in half, so that looking only at transmit/receive data transfer, the interval does not reach 12.5T.

However, there is the possibility that command execution and status report will be inserted asynchronously depending on the timing and thus the interval may possibly be 12.5T. Since this transfer is input asynchronously, it cannot be made to happen at any desired time.

If packet having the I field with a length equal to or greater than the set value of the N1 parameter is received from the line, what is the operation of the uPD72107?

Also, do the long frames that are counted as part of the number of long frame receptions in the statistical information read status consist of frames that have packets longer than the I field length specified by the N1 parameter?

Since the number of long frame receptions in the statistical information read status is counted up when the data part of the error check deletion frame exceeds N1, long frames are not counted if they exceed N1 of normal frames.

Moreover, if a frame that exceeds N1 is received, the processing specified by X.25 is performed and the fact that it has been received is not notified to external.

If an I field with a length greater than the value set by the N1 parameter is received in a normal frame, how is DMA to the receive buffer of external memory performed?

Also, does long frame check in a non-transparent mode check if the data length equal to the total of the address field + control field + information field is greater than the value set by the N1 parameter?

Further, how is DMA to the receive buffer of external memory performed during long frame reception in a non-transparent mode?

Regarding error frames (which, in this case, also include N1 over frames), data is transferred once to the receive buffer, but BRDY does not become FFh and INT is not output.

The next normal frame that is received transfers data to that receive buffer, overwriting it.
This operation is performed on the host interface, and is common to the regular LAP-B mode and transparent mode.

However, in the case of the transparent mode, FCS error check is switched depending on the mode. The definition of N1 is fixed by X.25 and it is the I field length. Note, however, that in the transparent mode, the A and C fields do not exist.

Does the uPD72107 operate in the same way after assertion of HLDRQ, both of when HLDAK is input for a clock, and when HLDAK is input until deassertion of HLDRQ?

Basically, always input HLDAK = "H" during the bus master transfer period.

Supplement
If HLDAK is forcibly made "L" during the operation, the bus cycle at that point in time ends.
The uPD72107 samples HLDAK at every rising edge of the S3 state of CLK during the bus master period, and determines whether to execute the next bus cycle accordingly.

Therefore, even if HLDAK is forcibly set to "L" for some cause, the bus cycle until then is executed without problem, and when HLDAK is set back to "H", the remaining bus cycles are also executed.

However, since forcibly setting HLDAK to "L" has a major impact on communication data transfer, it is not recommended.
Customers should exercise great care when performing the above.

I use the uPD72107 in the X.25 mode.
Does the link state given to parameter LSTN described in "N2 times retransmission out LSW" indicate that the LSI link state changes to the link state indicated by LSTN?

The LSTN parameter in a status indicates the link state immediately before the status report.

I use an LAP-B board on which the uPD72107 is mounted.
The link settings are received from the remote station.

According to the state transition table, returning DM (P = 1) in response to SABM (P = 1) from the remote station during communication reconnection indicates the link setting impossible and disconnection UA response wait state.
At what timing does the state become the link setting impossible state?

The timing is when the link close command is output.

Is it possible that, following the physical disconnection of the line from the link connected state, the state remains the link setting impossible state upon recovery?

No.

When link reset occurs, 0x06 sometimes be written exceeding the status table, but is there a way to avoid this?

During 4-byte block transfer, such occurrence is possible.
Set 8-byte block transfer.

If a long frame having the I field with a length equal to or greater than the set value of the N1 parameter is received, are the received long packets all written to the receive buffer of external memory, or is the data that exceeds the set value of the N1 parameter discarded?

(Example: If 256 bytes is set by the N1 parameter and a long frame with an I field length of 300 bytes is received, is the I field length written to the received buffer 256 byte or 300 byte?)

The size of the receive buffer is specified by the N1 parameter, and any receive data in excess of this value is discarded.

When using external memory while issuing the MSET command, is it correct to assume that the MSET command is written 1 byte at a time to address 0, in the same way as when an internal FIFO is used?

Is it OK to issue CRQ continuously describing multiple bytes to external memory, in the same way as for the command table?

No. Moreover, the internal FIFO method also differs.
Similarly to other commands, issue CRQ after writing all the parameters of the MSET command.

In either of the above cases, is it not possible to write the next command unless CRQURDY is monitored? (is a 10 ms wait required?)

Yes, that is correct. In the case of the MSET command only the CKST field is not updated, making this 10 ms wait necessary.

The memory of receive buffer specifies the 1XXXXh area, but it looks like the data is written to the 0XXXXh area.
I.e., it looks like a 16-bit address space (A17 to A23 = shadow?)

Regarding reception and all the tables, allocations to space A16 to A23 is also possible.
A16 to A23 are pins shared with higher data I/O in the word mode.

Therefore, it is necessary to perform address latching to external.
Also, the order of H, M, and L in each table can be changed with the DBOM parameter.

How is the transmit/receive clock used when using the loopback function?

The conditions are as follows.
MRSC-CLK is set to 00 and external input is used. (The TxC/RxC input clocks are asynchronous.)

(1) If MRSC-LPB is set to 01 (loopback mode 1), I believe TxC is used as the transmit clock, but what about the receive clock?
(2) If MRSC-LPB is set to 10 (loopback mode 2), what is used for the transmit/receive clocks?
(3) If MRSC-LPB is set to 11 (loopback mode 3), what is used for the transmit/receive clocks for data loopback to external? And what is used for the transmit/receive clocks for data loopback to internal?
(4) If all of (1) to (3) operate using an external clock, is it necessary to supply TxC/RxC corresponding to the clock mode to the LSI?
(5) During loopback testing, does TxC sometimes forcibly become an output pin?

Since the loopback function of this LSI serves to internally loop and connect TxD and RxD, the transmit/receive clocks must be input in the same way as during regular communication.

In other words, it is necessary to input the TxC clock for transmit frame shift-out, have that transmit frame looped internally and input it to the reception block as a receive frame, and input the clock synchronized with the receive frame for that shift-in operation to RxC.

Tracking this back, the same clock as TxC can be input to RxC.
As a result, in all cases, the same clock can be input for TxC and RxC.
By the way, the looped-back data does not go through the DPLL circuit, so the DPLL mode cannot be used.

Moreover, since there is no transmit/receive clock generation function in this LSI, clock input is required for TxC (except in the DPLL mode) and a clock synchronized to the receive frame must be input to RxC (except in the DPLL mode), and TxC never changes to output depending on the value set for the loopback function (except in the DPLL mode).

Use with 8 MHz as the system clock is recommended, but if a clock other than 8 MHz is used, are there any other problems besides the timer step value setting?

As a rule, use with the 8 MHz clock is recommended.
The system clock serves not only as the internal timer source clock, but also as the master clock for internal CPU execution and DMA transfer.

Therefore, if this clock frequency is low, the internal CPU operation becomes correspondingly slow.
If the communication speed is low, such as 2400 bps or 4800 bps, there is no great problem, but if the communication speed is high, between several tens of Kbps to Mbps, the internal processing must also be performed at high speed.

If the clock is slow, the processing that is demanded will exceed the CPU's processing performance, which may cause unforeseen problems.

What are the timer step values when the following clocks are input as the system clock input? Also, what is the calculation method?
(1)  4.9152MHz
(2)  2.4576MHz
(3)  1.2288MHz

The timer step value becomes 8 ms (or 100 ms) during 8 MHz operation. When the frequency is lowered, the timer step value becomes longer in inverse proportion.
Each Tx (X = 1, 2, 3, 4) is obtained with the following equation.

Tx = (constant set with SPST) * Timer step time * 8 / CLK frequency (MHz)

I am using the uPD72107 with the clocks (TxC/RxC) on the line when DPLL used in the transmit/receive clock mode 01 (operation mode setting MRSC: CLK), where the transmit/receive clocks are generated by dividing the clocks input from RxC by 16.

Under this condition, if the RxC clock has stopped, do the TxC clock for transmission and the transmit data TxD also stop at the same time?

Yes they stop.
When CLK = 01, the transmit clock is generated by dividing the clock input from the RxC pin by 16, and is output from the TxC pin.

Therefore, when the RxC input stops, the transmit clock also stops, and the TxD output transmitted based on that clock also stops.

In the frame flag sequence, is it possible to share the start flag and the end flag?
(Is there no problem even if a shared frame is received?)

It is possible for reception.
For transmission, sharing is not possible because at least 1 idle flag is inserted between the end flag and the start flag of the next frame.

Upon occurrence of an HDLC procedure anomaly during communicating with the exchange, investigation with a protocol analyzer shows that the uPD72107 perceives normal RR as sequence number abnormal RR, and FRMR is output.

Given the lack of detailed information, quantitative speculation is not possible, but the following are possible causes based on the information that you have provided.

First, looking at the occurrence you describe, based on the fact that transmission and reception of three frames occur almost at the same time (on the order of a few ms), the following three interrupt sources may occur in the LSI at almost the same time.

a. I frame transmission end processing (completion of transmission of last data from internal DMAC)
b. I frame reception end processing (startup upon end flag reception)
c. RR frame reception processing

It may be possible to avoid this problem by raising the CLK frequency of the uPD72107.