• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 274 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.

AM2434: About the PWM output

Satoshi Katayama
Prodigy 70 points

Part Number: AM2434

Is there any hardware mechanism within the AM2434 PWM output functionality that prevents the generation of short‑circuit (shoot‑through) patterns inside the microcontroller?

In my development, the PWM output function of PRU_ICSSG0 is being used.

Does PRU_ICSSG0 have any built‑in hardware mechanism to prevent the output of shoot‑through patterns (i.e., both U+ and U− are High, both V+ and V− are High, and both W+ and W− are High)?

Additionally, how about the ePWM ports—do they provide any such hardware protection mechanism

  • 0
    TI__Mastermind 24755 points

    Hi,

    Satoshi Katayama said:

    Does PRU_ICSSG0 have any built‑in hardware mechanism to prevent the output of shoot‑through patterns (i.e., both U+ and U− are High, both V+ and V− are High, and both W+ and W− are High)?

      PRU_ICSSG0 does NOT have dedicated hardware shoot-through protection, this has to be implemented in the PRU Firmware code if there is a requirement.

    Satoshi Katayama said:
    Additionally, how about the ePWM ports—do they provide any such hardware protection mechanism

    The AM2434 ePWM modules have built-in hardware mechanisms to prevent shoot-through.The ePWM module includes a dedicated dead-band sub-module that automatically inserts delays:

    • Rising-Edge Delay (RED): Programmable delay (0-1023 cycles) for the rising edge
    • Falling-Edge Delay (FED): Programmable delay (0-1023 cycles) for the falling edge
    • Configurable via EPWM_DeadbandCfg structure (source/drivers/epwm/v2/epwm.h:791-809)
    • Can be applied to complementary PWM outputs (A and B)

    Please refer to Section 12.4.3.4.5 in TRM for detailed explanation of this submodule.

    Best Regards,
    Meet.

  • 0 in reply to Meet Thakar
    Prodigy 70 points

    Hello,

    Thank you for your answer.

    Is this still effective even in the event of an unexpected reset?
    The reason I ask is that we are currently implementing a PWM output function on the PRU core. When a reset (or temporary halt) occurs only on the R5F due to noise or similar factors, the PRU core continues operating on its own, resulting in a short-circuit pattern being output.

    Could you please explain the behavior of the ePWM in the event of a reset caused by noise or similar disturbances?

    The following is the related URL.

    e2e.ti.com/.../am2434-reset-specification

  • 0 in reply to Satoshi Katayama
    TI__Mastermind 24755 points
    Satoshi Katayama said:
    When a reset (or temporary halt) occurs only on the R5F due to noise or similar factors,

    Could you elaborate this? Are you deliberately trying to reset only the R5F core in these scenarios? Any Hardware faults shouldn't just reset the R5F Core, it should trigger the reset of entire SoC or the main domain.

  • 0 in reply to Meet Thakar
    Prodigy 70 points

    On the board currently under development, an unintended microcontroller reset occurred, most likely due to noise entering through MCU_RESETz.

    During this event, only the R5F was reset, while the PRU cores appeared to deviate from the normal reset sequence and continued running before and after the R5F reset.

    We have previously submitted a technical inquiry regarding this issue; however, because the microcontroller entered an abnormal state, we have not been able to identify the cause of this reset behavior.

    For this reason, we would like to confirm whether ePWM provides a more robust and fail-safe mechanism than the PRU cores in the event of an abnormal microcontroller reset. Specifically, we would like to understand whether ePWM is less likely to continue operating unexpectedly or enter an uncontrolled state under such abnormal reset conditions.

    If ePWM is designed in a way that makes it less susceptible to unintended behavior during abnormal resets compared to the PRU cores, we are considering migrating this functionality from the PRU cores to ePWM.

  • 0 in reply to Satoshi Katayama
    TI__Mastermind 24755 points

    Hi,

    Please allow me sometime to review this, please expect a response by end of this week.

    Best Regards,
    Meet.

  • +1 in reply to Meet Thakar
    TI__Mastermind 24755 points

    Hi,

    Only R5F resetting due to a hardware fault is not expected unless you have enabled PRU isolation. If the entire MAIN domain undergoes a reset then your ePWM module will also undergo a reset and will not be operational.

    If what you are observing is correct and only R5F core enters reset (not the entire main domain) then ePWM will enter an uncontrolled state as R5F didn't power-off the ePWM module before entering the reset sequence.

  • 0 in reply to Meet Thakar
    Prodigy 70 points
    Thank you for your response. I understand that even if a reset occurs due to a microcontroller malfunction, the dead-band submodule may be able to retain its state in hardware. Therefore, it appears to offer advantages over implementing the functionality entirely in the PRU.

    Thank you very much for your support and assistance.