Datasheet

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 www.ti.com
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 Figure 24-
9, 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 NHET
instruction generates a request on DCP x. The arrows in Figure 24-9 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.
24.2.4.1 Requests and Quiet Requests
In addition to generating too many transfer requests and thus overloading the HTU and not being able to
transfer data at all, it can happen that inconsistent data is transferred. The following examples illustrate
such scenarios.
In the examples below, the HTU reads a frame of three elements from the datafield of three different
instructions. In Figure 24-10, the L3-Instruction generates the HTU request at time t2, t7, etc. and the
according frame (at t3). The frame is delayed because of the HTU load. However, as shown in Figure 24-
10, the delay still allows the frame to complete before the datafield of instruction L1 is updated again.
However, when the delay is longer (as shown in Figure 24-11), then the frame could fall into the NHET
loop (LRP), in which the NHET updates the data fields of the L1, L2 and L3 instructions. In this case, the
HTU could read inconsistent data as shown in the diagram. A wrong (new) value is read from L1 (at time
t3), but correct ("old") values are read from L2 and L3 (at times t4 and t5).
1074
High-End Timer Transfer Unit (HTU) Module SPNU562–May 2014
Submit Documentation Feedback
Copyright © 2014, Texas Instruments Incorporated