Part Number: AM62L
Other Parts Discussed in Thread: AM625, TDA4APE-Q1, AM62A7
Tool/software:
HI TI experts,
I have queries related to supported reset inputs and reset status outputs
Supported Reset inputs
Recommended connections for Reset inputs
Supported Reset Status output(s)
Recommended connections for Reset Status outputs
HI Board designers,
Please refer below.
Supported Reset input and output signals
Connection recommendations
Recommendations when RTC mode is used
Sequencing of VDDS_RTC and VDD_RTC
VDDS_RTC and VDD_RTC needs to be powered before RTC_PORz is released
There is no sequencing requirement between VDDS_RTC and VDD_RTC.
The only firm sequencing requirement for the AM62Lx processor is VDD_RTC up before and down after VDD_CORE.
RTC_PORz delay when RTC mode is configured
The RTC_PORz provides an asynchronous reset to the RTC domain and puts the logic is a known locked state until the VDD_CORE ramps. The LF oscillator is turned off by default. Once VDD_CORE ramps the RTC domain will partially unlock and start receiving its clock from the RC oscillator until software completes the unlock process by configuring the RTC domain. There is a glitch-free clock multiplexer that can be reconfigured from its default RC oscillator to select the LF oscillators after software has turned on the LF oscillator and waited 100ms for it to start. The max startup time for the LF oscillator with a crystal circuit is 98ms.
Based on the above operation the customer only needs to ensure the VDD_RTC and VDDS_RTC power rails are valid before they release RTC_PORz.
RC is used for RTC_PORz
We do not recommend an RC generated reset because the signal rising slew rate is too slow to get a glitch free reset inside the device.
SK RTC Only mode power supply architecture - a diode added to the VDD_RTC supply. Not sure on the use case
VDD_RTC needs to ramp up before VDD_CORE and down after VDD_CORE. Without the diode the VDD_RTC power rail could decay at the same time or before VDD_CORE when there is a uncontrolled power down, where the system power supply is turned off or disconnected from the board. The VDD_RTC power domain doesn’t draw much power, so the input capacitors on the VDD_RTC LDO will hold the VDD_RTC rail valid for a long time when it is isolated from the input power supply with the diode.
If there is a short interruption, the VDD_RTC supply may not decay to less than 0.3V before next power-up and I suspect this is not a concern.
We do not expect a problem for this use case because the VDD_RTC power rail is expected to be one of the first power rails to turn on and the last to turn off. Plus the VDDS_RTC LDO will assert RTC_PORz as its output begins to decay and will also assert it again as its input begins to ramp after the short interruption.
32K LFOSC0 clock when RTC mode is not used
Can you please confirm if the 32K crystal can be a DNI and customer can follow the data sheet recommendation to connect Xi to ground when low power modes are not used?
The low-frequency oscillator is not required to be connected when none of the RTC low power modes are being used. Follow the processor connection recommendation when LFOSC0 is not used.
Recommendations when RTC or low power modes are not used
Customer does not use low power modes. Is there a recommended connection for VDD_RTC, VDDS_RTC and RTC_PORz
In the case where no low power mode is used:
VDD_RTC is connected to the same 0.75V power supply that is powering VDD_CORE.
VDDS_RTC is connected to the same 1.8V power supply that is powering VDDS_OSC0.
RTC_PORz is connected to the same reset source that is sourcing PORz
On the AM62L, PORz is 3.3V tolerant.
Wanted to check id the RTC_PORz is also 3.3V tolerant. Based on the data sheet I do not see the RTC_PORz being 3.3V tolerant.
The use case for the query is when RTC only or RTC + IO + DDR mode is not used, we are recommending connecting the input connected to PORz to be connected to RTC_PORz.
PORz is the only 3.3V tolerant pin. The RTC_PORz pin is not 3.3V tolerant.
In this case, the signal sourcing these two pins will need to be sourced from the same IO power supply that is sourcing VDDS_RTC because the voltage applied to the RTC_PORz pin needs to track VDDS_RTC since it is limited to the range of -0.3V to (VDDS_RTC IO supply voltage + 0.3V).
The PORZ pin is powered from VDDS_OSC0, but it is okay for it to be sourced from VDDS_RTC since it is fail-safe. In the case you describe, I would expect VDDS_RTC and VDDS_OSC0 to be sourced from the same 1.8V power supply. However, I’m not aware of any problem if there is a system requirement to source VDDS_OSC0 from a different 1.8V supply than the one used to source VDDS_RTC.
Regards,
Sreenivasa
Hi Board designers,
Usually add RC filter on RESET signal to anti noise, but the slew rate requirement of RESET signal on AM62x datasheet is quite sharp, on customer board it is about 10V-100V/ms, can it meet AM62x reset requirement, if not please help to explain the basic mechanism.
There can be long-term reliability issues associate with the input buffer if the applied signal spends too much time in the voltage region between VIHSS and VILSS. The maximum transition time allowed is 1000ns. I recommend driving the reset input with a push-pull buffer that produces a signal transition rate that is faster than 5ns to eliminate the risk of noise coupling into the signal as it transitions through the input buffer switching threshold.
A 22 pF glitch filter is recommended at the input of MCU_PORz
another important point about the MCU_PORz input slew rate. It is very easy for noise to couple on slow rising signals such that it creates non-monotonic transitions. Your MCU_PORz reset source needs to be monotonic to prevent the chance of creating glitches on internal reset as it transitions through the input buffer switching threshold. A faster slew rate on the MCU_PORz will increase your system noise immunity. The min slew rate defined in the AM625 datasheet is acceptable to the AM625 device but may not be acceptable for your system noise immunity requirements.
Please keep in mind the AM62x device requires the MCU_PORz input to have a maximum rise/fall time of 1000ns. This may be difficult to achieve with a pull-up on a signal sourced from an open-drain output buffer. You may need to buffer the open-drain signal with a push-pull buffer that has hysteresis on its input to ensure the AM62x device never receives a short reset pulse that violates the minimum pulse duration defined in the "MCU_PORz Timing Requirements" table. For example, it may be possible for noise to couple on the slow rising open-drain signal just as it crosses the input buffer threshold which could cause a short glitch on the reset signal. Normal device operation could be compromised if this occurs.
See the "Input Slew Rate" parameter in the "Fail-Safe Reset (FS RESET) Electrical Characteristics" table.
The MCU_PORz input is the only input on the AM62x device that is fail-safe and 3.3v tolerant. Therefore, you can pull the MCU_PORz signal to 1.8V or 3.3V.
See the "Steady-state max voltage at all fail-safe IO pins" parameter for MCU_PORz in the "Absolute Maximum Ratings" table.
Note: The MCU_PORz description above is valid for the AM62L PORz cold reset input.
(+) AM62A7-Q1: MCU_PORz slew rate - Processors forum - Processors - TI E2E support forums
Regards,
Sreenivasa
Hi Board designers,
FYI
RESETSTATz during reboot (software warm reset)
after each reboot, RESETSTATz will be pulled low for 220 µs, and eMMC_RSTn is affected by the action of RESETSTATz.
Regards,
Sreenivasa
Hi Board designers,
FYI related to reset input causing the bord not to boot.
(+) AM623: Stuck in Reset - Processors forum - Processors - TI E2E support forums
The MCU resetz and warm reset (reset_reqz) seems to be controlled by the MCU.
Can you please confirm the signals are high during power cycle.
MCU_RESETZ and RESET_REQ_z were being pulled down by default by the MCU preventing boot. Programming the MCU to pull the lines high lets the processor out of reset and we are able to see "C" being printed by the UART bootloader on UART0.
Regards,
Sreenivasa
Hi Board designers
TDA4APE-Q1: Capacitance for MCU_PORz
Please tell me input capacitance of MCU_PORz port?
Here are the steps to determine the input capacitance on a specific IO:
Customer would like to know the exact value of the input capacitance of LVCMOS PIN.
Could you share it ?
The IBIS models have C_pkg (package capacitance, universal min/max for all pins) and C_comp (die capacitance, unique for each buffer type) that can be combined together to get the total capacitance for a pin.
Regards,
Sreenivasa
AM62A7
if the MCU R5F is not configured as a safety processor then the SW_MAIN_PORz should not be used as it will cause a device reset instead of a main domain reset. Only when the MCU R5F is configured as a safety processor, can we really make use of that register to reset the main
1. Data Loss on Reset:
• When an MCU reset is triggered, all previous data is lost.
• This includes the contents of both MSRAM and DDR memory.
• The AM62A device does not have any backup memory that retains data after a MCU WarmReset.
2. Reset Trigger Methods:
• The MCU reset can be initiated in two ways:
• Hardware Reset Pin
• Software-triggered Reset via the MCU MMR (Memory-Mapped Register)
3. Peripheral De-initialization Not Required:
• After an MCU reset, the core starts freshly from the boot.
• Therefore, manual de-initialization of peripherals is not required.
• The MCU firmware will re-initialize all peripherals as part of its boot process.
4. Watchdog Timer (WDT) Behavior:
• The WDT continues to run until the reset signal is fully propagated to the MCU core.
• Once the MCU core receives the reset signal and the WDT is re-initialized and WDT is starts freshly .
5. Reset Propagation Impact:
• MCU Reset is propagated through both MAIN and MCU domains. So, the DDR and MSRAM content will be lost .
Could you please explain the meaning of "IOs are not affected." as stated in the MCU Domain Effect and MAIN Domain Effect? I interpreted it to mean that GPIOs are not affected by the reset (i.e., they do not change even if a reset occurs), but I confirmed that when I actually performed a reset, the GPIO that was outputting High changed to Low. I would like to accurately understand the scope of the reset's effects, so I would appreciate your response.
Here, IO refers to Pinmux and Padconfig settings (such as mux mode, pull up/down controls, RX/TX active/disable controls etc.) controlling the IO buffer. During, warm reset, these are not reset. However, when you assign a pin to a certain module, in this case GPIO, when the main domain gets a warm reset, it will reset the GPIO module. If you previously configured a GPIO module as an output, it will go back to the reset state (which is input).
If you need a GPIO pin to not reset to the main warm reset, then you will have to use MCU GPIO and enable MCU Reset Isolation.
In AM62X, the MCU domain consists of an M4F core, whereas in AM62A, it consists of an MCU R5F core.
If you isolate the MCU domain while performing a Warm Reset or Power-On Reset (POR) on the MAIN domain, the MCU R5F/M4F core can retain its content in both SOC's.
However, if both the MAIN and MCU domains undergo a reset, the RAM content is not retained. This behavior is not supported in AM62A as well.
For further details, please refer to the FAQ below, which explains how reset behaves in scenarios with and without reset isolation.
RE: AM6442: Inter-Core Reset Isolation Between Main Domain Cores ( A53 and R5F)
In AM64X, the MAIN domain has R5F cores and A53 cores and the MCU core has M4F cores.
So, only the M4F core is isolated from the main domain in the isolation.
It is not possible to isolate the Reset from R5F or A53 and only isolate the Reset from the M4F core.
1, what are the functions of MCU Domain in this SOC?
SOC hardware
The concept of MCU and Main only applies to internal device functions and processor domains. The device does not have separate MCU and Main power domains.
All power rails must be powered, and they must be sequenced as defined in the datasheet.
Internal Function:
Functionalities related to safety and low latency are implemented using the MCU domain.
MCU_PORz, a cold reset signal, resets the entire SOC or just the MCU Domain when triggered?
Asserting MCU_PORz during power cycle or normal operation resets the complete SOC.
The Reset status is indicated by PORz_OUT (buffered output of MCU_PORz), MCU_RESETSTATz (completion of MCU domain reset) and RESETSTATz (completion of mani domain reset).
RE: AM2434: About the Reset Specification
By default, is the PRU reset isolated from the MCU and MAIN domains?
No
PRU-ICSS is expected to be configured for reset isolation to work.
RE: AM6442: Is MCU only (M4F) reset possible?
when i try to reset the only m4f with SOC_generateSwWarmResetMcuDomain() function, both of mcu and main domains are resetting.
Yes, this is expected behavior only. When MCU Reset, then reset will be effected for both MAIN and MCU cores and this is how SOC works.
But we are planning to use the system without Ethernet switch also. In that case, how the data transfer will happen between the MCU domain -Main domain (ignore SPI interface data transfer due to lower data transfer limit).
You can use IPC to transfer the data between them. Here, you can pass the DDR address space in IPC to other domain, as DDR is accessible other domain can read DDR directly no need to pass whole ethernet data.
AM2432: Reset R5 core from MCU domain
AM2432: Communication between MAIN domain and MCU domain when FFI is configured
Regards,
Sreenivasa
