5 4 3 2 1
5 4 3 2 1
5 4 3 2 1
5 4 3 2 1
1
2
5 4 3 2 1
1
2
3
4
TU request (1)
Element Counter
TU request (2)
Element Counter
TU request (3)
ElementCounter
5 4 3 2 1
5 4 3 2 1
5 4 3 2 1
1
2
3-L
4
3-L
Module Operation
1140
SPNU563A – March 2018
Copyright © 2018, Texas Instruments Incorporated
High-End Timer Transfer Unit (HTU) Module
24.2.3 Conditions for Frame Transfer Interruption
If a frame is currently transferred on DCP x and one of the events listed below happens, then the event
will (1.) clear the element counter of DCP x, (2.) stop new element transfers on DCP x (3.) clear the active
busy bit of DCP x and (4.) disable DCP x in the CPENA register. The DCPs other than DCP x will not be
affected.
•
Request Lost Error of DCP x (with CORL bit set to 0).
•
Parity Error of DCP x (with parity check enabled and COPE bit set to 0). See also
•
Bus Error of DCP x.
•
Memory Protection Error of DCP x (with memory protection enabled). See also
•
Writing a 1 to a BUSY bit (belonging to DCP x) if that bit is 1. There is no effect if the BUSY bit is 0.
•
Writing a 1 to the HTURES bit.
When a memory protection error occurs, the access to the protected address is blocked. The frame is
stopped before the element, which caused the violation transfer, starts. All other errors will let the current
element transfer finish.
In case of the Request Lost and Bus Error, one more element transfer goes on the bus, before the frame
is actually stopped. Accordingly, the busy bit is cleared after the element, which follows the element that
caused the error.
In case of the Bus Error, the counter for the element, which follows the element that caused the error, is
captured to the ERRETC register field.
NOTE:
If the HTUEN bit is cleared during a frame is transferred, then the frame will be completed
before the HTU is disabled.
24.2.4 HTU Overload and Request Lost Detection
If the number of different HTU request sources is "high", the period between the requests is "short" and/or
the initial element counter values are "big", then the HTU could get into a overload situation. In
, all requests marked with "L" are lost, since their frame is not completed at the time the next request
occurs. Each number in the rows "TU request (x)" represents a time, where the associated N2HET
instruction generates a request on DCP x. The arrows in
point to the associated frame, which
could be delayed compared to the request. The delays are caused by different frames, which are currently
processed. The figure assumes that the CORL bit in the RLBECTRL register is set, which causes the DCP
to stay enabled and let the data stream continue after a request lost error occurred on the DCP (see 3-L
for TU request (2)).
Figure 24-9. Timing Example Including Lost Requests
Lost requests are signaled with the RLOSTFL register, and if enabled, can generate request lost
interrupts.
If the CORL bit is set, a frame will be completed and the corresponding DCP stays enabled even if a
request lost was generated during this frame.
In dual buffer mode, the request lost detection works continuously, independent of the CP switches.