If an interface other than RS-232 is desired, the MON shim can be replaced with an alternate function. For example, the MON shim could be replaced with a custom processor interface or other scheme for inter-process communication. When replacing the MON shim with an alternate function, it becomes critical to understand the behavior of the controller monitor interface.
For an overview of the signals, see Monitor Interface section. The data exchanged over this interface is ASCII. For a summary of the status and command formats, see the Monitor Interface Commands and Monitor Interface Messages sections.
This Figure illustrates the protocol used on the transmit portion of the Monitor Interface. When the controller wants to transmit a byte of data, it first samples the monitor_txfull signal to determine if the transmit buffer is capable of accepting a byte of data. Provided that monitor_txfull is Low, the controller transmits the byte of data by applying the data to monitor_txdata[7:0] and asserting monitor_txwrite for a single clock cycle
.
The controller can perform burst writes by applying a data sequence to monitor_txdata[7:0] and asserting monitor_txwrite for multiple cycles. However, the controller observes monitor_txfull so that it never over-runs the transmit buffer.
It is the responsibility of the peripheral receiving the data to correctly track its buffer availability and report it through monitor_txfull . In the cycle after the peripheral samples monitor_txwrite High, it must assert monitor_txfull if the data written completely fills the buffer.
Further, the peripheral must only assert monitor_txfull in response to monitor_txwrite from the controller. Under no circumstances can the peripheral assert monitor_txfull based on events internal to the peripheral. This requirement exists because the controller can sample monitor_txfull several cycles in advance of performing a write.
While monitor_txfull is asserted by the peripheral, the controller stalls if it is waiting to transmit additional data. This can have negative side effects on the error mitigation performance of the controller. For example, if a correction takes place, the controller successfully corrects (or handles) the error and then send a status report. If the entire message cannot be accepted by the peripheral, the controller stalls, preventing it from returning to the observation state. Therefore, a custom peripheral must have an adequate balance of buffer depth and data consumption rate.
This Figure illustrates the protocol used on the receive portion of the monitor interface. When the controller wants to receive a byte of data, it first samples the monitor_rxempty signal to determine if the receive buffer is providing a byte of data. Provided that monitor_rxempty is Low, the controller receives the byte of data from monitor_rxdata[7:0] and acknowledges reception by asserting monitor_rxread for a single clock cycle.
The controller can perform burst reads by obtaining a data sequence from monitor_rxdata[7:0] and asserting monitor_rxread for multiple cycles. However, the controller observes monitor_rxempty so that it never under-runs the receive buffer.
It is the responsibility of the peripheral providing the data to correctly track its buffer status and report it through monitor_rxempty . In the cycle after the peripheral samples monitor_rxread High, it must assert monitor_rxempty if the data written completely fills the buffer.
Further, the peripheral must only assert monitor_rxempty in response to monitor_rxread from the controller. Under no circumstances can the peripheral assert monitor_rxempty based on events internal to the peripheral. This requirement exists because the controller can sample monitor_rxempty several cycles in advance of performing a read.
During the initialization state, the controller purges the receive buffer by reading and discarding data until it is empty. The controller assumes the transmit buffer is ready immediately and does not wait for the transmit buffer to empty, as it has no way to observe this condition.