AM2434: Unexpected Reset Behavior on AM2434 When Switching Circuit Operates

Part Number: AM2434


Description:
I am investigating the internal reset circuitry of the AM2434 because I am experiencing unexpected resets when operating an external switching circuit. The device behaves as if it has been reset during this operation.
According to the datasheet (Figure 6-5), RST3 (Power-On Reset) requires an off time of 1200 ns. However, I would like to know if there are other conditions that could cause MCU_RESETSTATz or RESETSTATz to assert.
Observations:
  • I monitored PORz_OUT, MCU_RESETSTATz, and RESETSTATz on the board while the switching circuit was active.
  • All signals showed noise-like waveforms during switching.
  • PORz_OUT only had about 200 ns of noise, but MCU_RESETSTATz and RESETSTATz went low for the same duration as a normal reset pulse and then returned high.
  • After this event, when checking the CTRLMMR_RST_SRC register in CCS, bit 20 and bit 0 were set.
Questions:
  1. Besides the 1200 ns requirement for RST3, what other factors could trigger a reset on AM2434?
  2. What do bits 20 and 0 in CTRLMMR_RST_SRC specifically indicate in this context?
  3. Could switching noise on signals or power rails cause warm resets or other reset sources?
Reset.pngAny guidance or suggestions would be greatly appreciated.
  • Hello Tanaka-san,

    Can you please tell us more about the switching circuit? Is it a relay, semiconductor, etc.? What is the load ? Motor, inductive, resistive, etc.? A schematic part related to switching circuit will be appreciated.

    Thanks,

    Stan

  • Regarding Reset Source bits descriptions, please see snapshots from the TRM:

  • Hello,
    The application is a motor drive, and I suspect that surges are caused by switching the gate signal. However, my question is specifically about the AM2434 specifications.
    Under what conditions does RESETSTAT go low or a RESET occur after power-up on the AM2434? For example, when there is a surge, we observe signals that suggest the clock is fluctuating. What happens if the PLL loses lock? Also, if MCU_PORz goes low for a few nanoseconds, will that trigger a reset? In Figure 6-6 of the datasheet, the low time for MCU_PORz is not specified, and the specification (RST4) states that the minimum time for RESETSTATz to go low is 0 ns. Does this mean that even a momentary low can cause a reset?
    I have also referred to the TRM, but the description provided did not allow me to fully understand the details. After a normal power-on, when I checked the same register from CCS, only bit 20 was set. I have not used any gen scripts during JTAG connection, and I have not applied any JTAG reset. I expected bit 12 (COLD_OUT_RST) in this case.
    Finally, after power-up, when I wrote 4'b0110 to CTRLMMR_RST_CTRL.SW_MAIN_WARMRST from CCS and then checked the CTRLMMR_RST_SRC register, I expected only bit 21 to be set, but bit 20 was also set. Furthermore, after repeating the same procedure several times, bit 0 was sometimes set as well, so I cannot clearly understand the behavior of this register.
  • Hello Yusuke Tanaka-san,

    Thank you for the added details and clarifications  !

    The ticket owner is currently out of office for the Christmas holidays.

    Please expect a response between 26-th of December 2025 and 6-th of January 2026. 

    We appreciate your patience !

    Kind Regards,

    Anastas Yordanov

  • I have a new question regarding reset behavior on AM2434.
    The current setup runs ΣΔ current detection and motor-control PWM on the PRUs.
    I am concerned about unexpected resets and their impact on PRU and PWM operation.
    Questions:
    1. Is there a mode where the PRUs can continue running while only the Cortex-R5F is reset?
    2. During any reset event, can PRU output pins be forced into a specific state (e.g., a pattern that could cause short-circuit)?
    3. The issue started when a reset occurred immediately after starting PWM. On one occasion, after PWM started, the switching circuit shorted. If this was caused by a reset, is there any risk that:
      • PWM continues running alone during reset?
      • I/O pins remain in a short-circuit pattern during reset?
    4. Based on TRM Table 5-979 “Device Reset Sources,” I understand external pin-related reset sources are:
      • MCU_PORz HW Pin
      • MCU_RESETz HW Pin
      • RESETz_REQ HW Pin
        How can we identify which of these caused the reset when it occurs?
    5. How does CTRLMMR_RST_SRC reflect each of these reset sources?
    6. Is there any scenario where PRU does not reset and continues running when one of these reset sources is triggered?
    Thank you for your support.
  • Hello Tanaka-san,

    1. You can refer to TRM section 5.3.4.2 Reset Isolation

    2. Since this is an unwanted reset, plus there might be more things involved, I can't comment on impact on PRU pins

    3. PWM and PRUSS can continue operating if PRUSS was configured for reset isolation. Please see TRM section in 1.) 

    I/O pins remain in a short-circuit pattern during reset?

    This is not an intended behavior. POR reset would reset the registers, making PWM disabled and pins HiZ (POR default values). Warm resets can be isolated (not resetting PRUSS). The latter is software configurable.

    5. 

    • MCU_PORz HW Pin       -> PORz_OUT pin
    • MCU_RESETz HW Pin   -> bit 0 of CTRLMMR_RST_SRC register
    • RESETz_REQ HW Pin   -> bit 2 of CTRLMMR_RST_SRC register

    6. Yes, PRUSS can be reset-isolated from main domain warm resets. More specifically here, from pin resets on MCU_RESETz and RESETz_REQ.

    Generally, please note that the induced noise on your scope screenshot is with amplitude exceeding several times the maximum allowed in datasheet. This is  enough to observe unwanted behavior or even damage the SoC. Do you have an appropriate snubber/supressor circuitry on motor connectors to suppress switching noise?

    Thanks,

    Stan