This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

HTU: Waiting time for software reset needed

Other Parts Discussed in Thread: TMS570LS3137

Hello.

My question is regarding the device TMS570LS3137, module "High-End Timer Transfer Unit (HTU) Module".

In spnu499b.pdf, page 915, Table 21-11, Description of bit field GC.HTURES is stated

   "The recommended order of operations is:",

and as second point is stated

   "Wait for the HTURES bit to clear."

Since I'm working for a safety relevant project, I can not just use the following code:

// 1. Set the software reset bit. This also clears HTUEN:

GC.HTURES = 1;

// 2. Wait for the HTURES bit to clear:

while (0 != GC.HTURES)

{

    // do nothing except waiting

}

// 3. Configure the HTU registers and packets.

...

Reason why this code is no option: In case the GC.HTURES bit field has a stuck-at-1-error, the above while-loop would mutate to an ENDLESS loop. And possible endless loops are NO option in the safety-relevant project. So I have to implement the code with a timeout check, like in the following way:

// 1. Set the software reset bit. This also clears HTUEN:

GC.HTURES = 1;

// 2. Wait for the HTURES bit to clear:

volatile uint32 start = 10000;

while (start > 0)

{

    start--;

}

if (0 != GC.HTURES)

{

    // ERROR!!!

}

else

{

    // NO error.

    // 3. Configure the HTU registers and packets.

    ...

 }

My problem is now: I can not find an information about the WORST CASE time duration how long it would take between the following two events:

  * Event 1: Setting GC.HTURES to 1.

  * Event 2: GC.HTURES will be cleared to 0.

So I would ask you to provide me this WORST CASE time duration. If this WORST CASE time duration depends on several factors (e.g. configuration of other HTU registers), I would ask you to provide me an appropriate formula.

Thank you and regards

Oliver.

  • Oliver,

    Thanks for using our e2e forum.

    I've forwarded your question to our HTU expert.

  • Hello Oliver,

      Could you clarify if you will attempt to reset the HTU via the HTURES only in the HTU initialization? If this is the case then the software reset should take one VCLK2 cycle. When you write to the HTURES bit, it generates an internal clear pulse to clear other registers. If you are trying to do a software reset while the HTU is in the middle of a transfer then it will wait until the state machine is not busy before generating the clear pulse. Let me know if this answers your question.

    regards,

    Charles

  • Hi Charles.

    Thank you for the fast response.

    Since the project is a kind of a driver platform, I can not tell when the user of this driver platform will trigger an HTU reset. So the user will have the possibility to trigger an HTU software reset also in the middle of an HTU transfer.

    So If I understand you correctly, then the time duration between event 1 and event 2 (as stated in my post "Posted by Oliver Gr��ndonner on Feb 24 2014 09:59 AM" above) depends on the following two factors:
    * Factor 1: How many request lines are active at that point in time when GC.HTURES is set to 1.
    * Factor 2: The sum of the time duration of all HTU transfers, which are active cause of factor 1.

    So the WORST CASE would occur if ALL configured request lines would be active, and GC.HTURES is set to 1. And the WORST CASE time duration (between event 1 and 2) would be the sum of all HTU transfers, which will be triggered by ALL configured request lines.
    Am I correct?

    Regards
    Oliver.

  • Hello Oliver,

      The reset will be applied soon as the state machine is not busy. The state machine will be forced to finish the current element transfer. Please note this is only one element. For example, the HTU might be in the middle of transfering a 32-bit word to the CPU RAM buffer. Soon as the 32-bit word is complete the state machine will not be busy. The intention of waiting for the end of a transfer is to allow a clean termination on the internal bus protocol. So the time for this transfer will be much shorter than what you assume in factor 1 & 2.

    regards,

    Charles

  • Charles,

    in this case my question is answered.

    Thank you again for the fast response and regards,

    Oliver.