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.

TMS320F280049: Why forcing DACEVT1 doesn't shut down PWM (OST flag is not set)

Part Number: TMS320F280049

Tool/software:

Hi,

Why forcing DACEVT1 doesn't shut down PWM (OST flag is not set)?

In code, I set forcing flag DCAEVT1, it is reflected in TZFLG register, but only DCAEVT1 is set. According block schematic, also OST flag shall be set.

TZSEL.bit.DCAEVT1 is set.

Thank you

  • Hi Martin,

    Make sure TZSEL.bit.DCAEVT1 is properly configured. See below.

    When forcing TZFRC.DCAEVT1, the TZFLG for both DCAEVT1 and OSHT are being set.
  • Hi,

    I am sure that DCAEVT1 is set in TZSEL, look on this values:

    Thank you

  • Hi Martin,

    Can you run this test case and verify your test case with this one?

        uint16_t status = EPWM_getTripZoneFlagStatus(myEPWM1_BASE);
    // status should be 0xC

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/epwm_5F00_ex1_5F00_trip_5F00_zone_5F00_f28004x.7z

    Best regards,

    Ryan Ma

  • Hi Ryan,

    thanks for code, I was not able to run your whole project as I have different versions of compilator and C200Ware. But I copy your PWM initialization and it works. 

    So I found than one difference is in setting EVT1FRCSYNCSEL . In my code it is set to 1, in your to 0.

    I am wondering why this bit is affecting OST flag. Can you please confirm/explain?

    Red path has nothing to do with EVT1FRCSYNCSEL

    Thank you

  • Hi Martin,

    My only suspect is that because it is a Aysnc path.

    The final connection to the OR of all One shot events must be using the sycn'ed DCAEVT1.force with the OR of the TZFRC[DCEVT1] path. The async path seems to not be ORed with the TZFRC[DCEVT1] path. 

    I will need to follow up with our design team to get the final answer. This may take some time.

    But for now if you're using this path, you should use the TZFRC[OSHT] feature as a workaround.

    Best,

    Ryan Ma

  • Hi,

    thank you, for now I can work with this.

    I will be waiting for final answer from your team.

    Regards

    Martin

  • Hi Martin,

    I will keep this post up to date. 

    Best regards,

    Ryan Ma

  • Hi Martin,

    Still trying to get some answers from design. Apologize for the delay.

    Best regards,

    Ryan Ma

  • Hi Martin,

    I will be out of office from July 11th-18th. However since you have a work around I assume this issue doesn't halt your development. 

    When I come back I am still driving the debug to see why this issue occurs and provide some results. Apologize for the delay in response, but working on getting you some more information.

    Best regards,

    Ryan Ma 

  • Ok, no problem.

    Thank you

  • Hi Martin,

    I was able to find your answer. For F28004x, we need to update the TZ diagram for clarification. There are two paths taken after the EVTxSRCSEL mux output for Aysync and sync.

    For TZFRC.DCxEVTy to occur and reflect in the TZFLG one shot registers, you need to use the sync path.

    If you do not use the sync path, and instead require the async path (DCxCTL.EVTxFRCSYNCSEL = 1), then you cannot use TZFRC.DCxEVTy to trigger the TZ one shot condition.

    However for devices like F2838x and newer, there was an update to this event triggering to add the option to latch the async path as well. The configuration for this would be 

    DCxCTL.EVT1FRCSYNCSEL = 1

    DCxCTL.EVTxLATSEL = 1

    Then you can use TZFRC.DCxEVTy to force a one shot condition.

    Best regards,

    Ryan Ma