• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 402 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

TMS320F28377S: AQCTLA [ZRO] event is not executed when "0" is loaded to TBCTR

TMS320F28377S:TBCTR's Problem

Sh.Sasaki
Guru 13625 points
Part Number: TMS320F28377S


Hi everyone,

Plase let me know the following link.

https://e2e.ti.com/support/microcontrollers/c2000/f/171/t/812087#pi320995=2

Is this problem described in the errata?
Or is this problem described in TRM?

  • 0
    TI__Genius 10845 points

    Hi Sasaki,

    I don't think it is a problem with device. The operation done itself is not an expected operation and would lead to inconsistent results.

    Thanks

    Vasudha

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    Thank you for your support.

    Vasudha Bhadoria said:

    The operation done itself is not an expected operation and would lead to inconsistent results.

    If that leads to inconsistent results, I think the TRM needs a note on this matter.

    Do you think there is no need for notes on TRM?

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    Please let me know, as I received the following confirmation request from the customer.

    (1) Is this behavior a specification and should not be considered in the errata?
         I don't think that's an errata, but please let me know just in case.

    (2) If this behavior was Errata, would you change the device's specifications without an announcement?
         This will not apply to PCN notifications when changing device specifications, but please let us know just in case.

    (3) If the specification has been changed, is there any problem with the current workaround (TBCTR = PRD-1)?
         It may be a strange question, but please tell me that the customer asked me to confirm it.

    I'm sorry for your inconvenience but thank you for your cooperation.

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    My customers want to get information quickly because they are currently in mass production phase.

    I understand you are occupied, but I would appreciate it if you could answer as soon as possible.

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    Do you have any information?

    Best regards,

    Sasaki

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    I'm sorry to ask you again and again.

    This issue can not be avoided only by writing in TRM. Please provide a note on this issue at the next update of the document.

    Best regards,

    Sasaki

  • 0 in reply to Sh.Sasaki
    TI__Genius 10845 points

    Hi,

    We did some further tests on the above scenario and concluded following:

    • The  issue occurs when software writes are aligned with TBCTR clock which results in  CNTR = 0 not getting recognized by the hardware. When some delay is added to software writes, the value gets recognised by hardware and we see the intended result. Also, the same can be achieved through writing (PRD - 1) 
    • Addition of delay doesnot work in cases TBCLK = EPWMCLK as the counter recognizes only the incremented value due to writes aligned with TBCLK.
    • Hence the fix (PRD - 1) willl work in all scenarios.

    Let me know if this resolves your query.

    Thanks

    Vasudha

  • 0 in reply to Vasudha Bhadoria
    Guru 13625 points

    Hi Vasudha-san,

    Thank you for your special support!

    My question has been cleared.

    Best regards,

    Sasaki