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.

AM2432: Reset Related Questions

Part Number: AM2432

Hi Team, 

My customer has a few questions regarding reset as below.

1) I expect that if we use CortexR5F core (in MAIN domain) only, we don't have to care about starting cortexM4F core(in MCU domain). but datasheet and TRM say that system clock is supposed to be input to MCU_OSI_XI terminal and cold reset is supposed to be input to MCU_PORz terminal. Both terminals belong to MCU domain, right?
Do you have some documents that describe the relationship between MAIN domain and MCU domain?

2) Figure 5-660 High Level Reset Flow in TRM says MAIN domain start first, and then MCU domain is boot up by MAIN domain.
Why does MAIN domain have warm reset (RESET_REQz) only?
Why does MCU domain have cold reset and warm reset?
Do you have recommended reset sequence for power on?
Do you have recommended reset sequence for reset while operating?

3) Regarding datasheet p196, is there Power On Reset circuit inside AM243x?  Asserting MCU_PORz at the timing shown in Figure 7-3 is needed?

Best regards,

Mari

  • Hi Mari,

    1) The terminal does belong to the MCU domain, the PLLCTRL0 inputs in the Main Domain are driven by default from the MCU_HFOSC0. The reason this does not conflict with the boot sequence of our device is because, by default, MCU_HFOSC0 is enabled right after MCU_PORz. This pin is held in reset until all power supplies are stable upon power-on. The reset chapter(5.3) shows the differences in the 2 domains from reset details.

    2) RESET_REQz is warm reset and enables the reset of the MAIN domain without interrupting any reset isolation domains.

    MCU_PORz is the cold reset and is for the whole device and resets both MAIN and MCU domain. The warm reset for MCU domain is MCU_RESETz similar to RESET_REQz for MAIN domain.

    The p196 of datasheet shows the sequence for power on sequence.

    While operating, warm resets can be used to reset each domain as per the use case. More details can be found in the reset chapter.

    3) MCU_PORz is required as per the timing shown in figure 7-3 of the datasheet and is the external power-on-reset for the whole device.

    Thank you,

    Anita

     

  • Hi Anita,

    Thank you for your quick support! I have a few follow-up questions as follows: (The numbers correspond to the question number from the original post)

    1. As they have said previously, they are only interest in using MAIN domain. According to TRM p2874 Figure 5-660 POWER-UP / RESET High Level AM64x SoC Flow, it seems like the MAIN domain boots up the MCU domain and releases it from reset. Do they have to boot / reset release the Cortex M4F?

    2. In the same figure as the question above (Figure 5-660), why is it that they do not warm reset the MAIN domain? Also, for the recommended reset sequence for reset while operating, is the warm reset sequence (TRM p2890 Figure 5-667 MAIN Domain Warm Reset Sequence Flowchart) adequate? Or is there some other sequence they can follow?

    3. I looked at the POR Module (TRM p2780 5.2.2.1.2 Power on Reset (POR) Module, is my understanding correct that MCU_PORz needs an external signal, but if they use the PMIC, the PGOOD signal from the PMIC is connected to MCU_PORz, and therefore PMIC will take care of the MCUC_PORz assertion ?

    Best regards,

    Mari

  • Hello Mari,

    I am following up here while Anita is OOO.

    1) Yes, even though the MAIN domain cores (R5FSSx) are not used in the application, the R5FSS0-0 core is still required for reset management and boot configuration. The M4FSS reset must be released once the SBL has completed loading the intended MCU domain application code.

    2A) A warm reset is not required for the MAIN domain since the diagram assumes the MCU_PORz (Power-On Reset) has been triggered and applied the reset to the entire device. Note that this is the only HW/Pin option for a device-level PORz cold reset.

    2B) The reset sequence that should be used is dependent on the system. In this case, a MAIN domain warm reset (RESET_REQz) will not be sufficient since the application is running in the MCU domain. The MCU_PORz, MCU_RESETz, and SW_MCU_WARMRSTz should be used in order to ensure the MCU domain is properly reset.

    3) Your understanding is correct from a high-level, however it is critical that system still adheres to the Power-Up Timing Requirements detailed in the device datasheet (https://www.ti.com/lit/gpn/am2434).

    Best Regards,

    Zackary Fleenor

  • Hi Zackary, 

    Thank you for your response. I realized in my last reply, I wrote that their interest was in the MCU domain. That was a typo on my part, and I meant to type MAIN domain as per the original post in this thread. Would you be able to give insight on the same questions as above, but from the MAIN domain perspective (assuming that they don't need/want to use the MCU domain if possible).

    Also, they have added a follow-up question as below:

    4.  We want our reset to function as so when the system is externally instructed, the system returns to the same state as if it were just powered on. If they want to achieve this, do they only need to drive MCU_PORz? Can RESET_REQz and MCU_RESETz remain high?

    Apologies for the confusion!

    Best regards,

    Mari

  • Hey Mari,

    The statements in the previous reply are still applicable from the MAIN Domain perspective, and the MCU_PORz pin would still be used as the device-level Power-On Reset.

    4A) Correct, driving MCU_PORz low (Logic 0) will issue a device Power-On Reset (PORz), this will restore the system to default state.

    4B) Correct, if the warm reset pins RESET_REQz and MCU_RESETz are not used/required they should be pulled high.

    Best Regards,

    Zackary Fleenor

  • Hi Zackary,

    Thank you for your response! 

    Just to confirm, even if they are not interested in the M4F core, they still need to boot it either ways because the M4F core needs to be released correct?

    Best regards,
    Mari

  • Hi Zackary,

    Any update on this?

    Thanks,

    Mari

  • Hello Mari,

    even if they are not interested in the M4F core, they still need to boot it either ways because the M4F core needs to be released

    If the MCU Domain is unused, then the M4F boot/core-release is not needed. However, the MCU domain peripherals are still accessible by the MAIN domain (even if the M4FSS is unused) but must be properly configured.

    Another point worth mentioning if the M4F core is unused: then the MCU_PORz device pin is the only PORz cold reset option (SW_MAIN_PORz MMR must not be used).

    Best Regards,

    Zackary Fleenor