AM4372: AM4372 Warm Reset Pin Behavior and Boot Issue

Hi Jack,

Let me dig into it. I will need some time to reply tomorrow or the day after tomorrow.

Thanks,

Stan

Hi Jack,

Jack said:

Is our understanding correct regarding the WARMRSTn pin behavior (input during ramp-up, output after boot)?

WARMRSTn pin is both input and output (open-drain) at all times. It is possible to use it as reset output to other devices and reset input to SoC, however only one of the directions is recommended as per TRM:

Please refer to TRM section 6.7.4.1 External Warm Reset for details.

Can you please help me understand, when do you want FPGA_nRST to be asserted to FPGA? For how long? Do you want it be asserted after every internal or external to SoC event or only after POR?

Thanks,

Stan

Hi Stan

Thanks for your support.

My customer has raised additional questions regarding an issue where noise from the FPGA is affecting the AM4372's WARMRSTn (G22) input, causing unintended reboots of the AM4372. Specifically, they would like to confirm the following:

1. Is the input buffer of the WARMRSTn pin (G22) implemented as a Schmitt trigger?
2. What are the input threshold levels (VIL and VIH) for the WARMRSTn pin (G22)?

Additionally, they are seeking design recommendations or ideas to prevent unintended resets of the AM4372 caused by noise from the FPGA. Any guidance on best practices to avoid such issues would be greatly appreciated.

Thank you for your support.

Best Regards, 
Jack

Jack,

For 1 and 2, I will check the documentation.

Meanwhile, can you ask them for better quality snapshot of the scope screen snapshot?

Jack said:

Additionally, they are seeking design recommendations or ideas to prevent unintended resets of the AM4372 caused by noise from the FPGA.

This was the reason asked for these questions:

Stanislav Stilyanov said:

Can you please help me understand, when do you want FPGA_nRST to be asserted to FPGA? For how long? Do you want it be asserted after every internal or external to SoC event or only after POR?

Can you ask them these too?

* By 'internal or external to SoC event' I meant 'SoC reset event'

Thanks,

Stan

Jack,

1. Yes

2. 

Hi Stan.
Thanks for your reply.

Here's a feedback from customer. 

WARMRSTn Pin Functionality Requirements

• Initial Boot Behavior: The WARMRSTn pin should be configured as an input during the initial boot phase.
• Post-Boot Behavior: After the boot process is complete, the WARMRSTn pin should be reconfigured as an output.
• Disabling WARMRSTn: It is desired to disable the WARMRSTn function after a certain period following boot completion. If disabling is possible, the pin should remain in a high state.

FPGA_nRST Signal Requirements

• Trigger Condition: The FPGA_nRST signal should be asserted when a CPU WARM RESET event occurs.
• Signal Duration: Since the FPGA_nRST pin is not a dedicated reset pin but rather a clock pin repurposed for reset via user logic, there is no strict timing requirement. A duration of approximately 10 clock cycles (around 100 ns) is considered sufficient.
• Reset Event Scope: The FPGA_nRST signal should be asserted for every SoC reset event, not just during power-on reset (POR), maintaining the current behavior.

During normal boot (WARMRSTn noise occurs; the right side shows a zoomed-in waveform at the moment of noise occurrence)

When a CPU WARM RESET occurs

Thanks.
Best Regards, 
Jack

Hi Jack, 

Thank you for the oscilloscope snapshots. 

It is hard to say if this noise can cause SoC reset because it's not reaching low enough level although it's very close. Did you have a chance to disconnect WARMRSTn from FPGA to confirm it's FPGA causing resets?

Regarding the main question - if you want to to make WARMRSTn output-only, you will need to add one additional (open-drain) buffer similar to that what you have between POR and WARMRSTn (74LVC1G07), this time between WARMRSTn and FPGA. This buffer will pass WARMRSTn signal to FPGA and not in the other direction. 

Note that WARMRSTn pin itself doesn't need to be driven externally (e.g. during boot) unless you need to warm-reset the SoC from external circuitry. WARMRSTn may be used purely as output only to external devices as described above.

Regards,

Stan

Hi Stan,

Thank you for your previous response.

On our board, when we disconnect the connection between FPGA and AM4372, the reset issue no longer occurs. Currently, the customer is requesting a scenario where the WARMRSTn pin is disabled during boot and then enabled again at the application start or at a specific point they require.

From your reply, I understand that your main recommendation is to use the WARMRSTn pin purely as an output and add an open-drain buffer (similar to the one between POR and WARMRSTn, e.g., 74LVC1G07) between WARMRSTn and FPGA to prevent reverse driving. Is that correct?

Additionally, could you please confirm if there is a register that allows us to temporarily disable the WARMRSTn pin function? The TRM mentions that it can be disabled through MMR registers, but we would appreciate your guidance on the exact register and procedure.

Thank you for your support.

Best regards,
Jack

Hi Jack,

Thank you for the inputs.

In the AM437x TRM I found a couple of registers belonging to the AM4372 Control Module used to control the WARMRSTn pin I/O properties .

We are going to internally discuss on how can be these used to temporarily tristate the SoC WARMRSTn pin and use it as a controlled reset output to the FPGA. We'll try to get back to you with a response early next week.

Thanks for your patience !

Kind Regards,

Anastas Yordanov

Hi Anastas.
Any update on this thread?

Regards, 
Jack

Hi Jack,

In our discussion we came to a conclusion which is in accordance with what the AM437x TRM recommends. The nRESET_IN_OUT pin shall not have a bidirectional usage. It might be better to initialize it as an output - setting the CTRL_CONF_NRESETIN_OUT[] CONF_NRESETIN_OUT_RXACTIVE=0b0 and CTRL_RESET_MISC[0] NRESETIN_OUT_CTRL = 0b0.  Is it acceptable for you to use an unreserved GPIO pin as input from the reset button and trigger a warm reset via flipping a bit in a register instead from the nRESET_IN_OUT pin ?  

Please let me know if you have any questions.

Thanks

Kind Regards

Anastas Yordanov