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.

AM625: Peripherals goes into reset state when processor goes into DeepSleep mode

Part Number: AM625

Hi support team.

We are using the AM62x processors in our products and are facing the following issues.

When SoC goes into DeepSleep mode the RESETSTATz output of the SoC is pulled down and puts the peripheral devices like Ethernet PHY, eMMC, DSI to LVSD bridge, etc. into the RESET state. This behavior creates issues on the SW side when SoC returns from the DeepSleep mode to the Active mode.

Is there any way to prevent the RESETSTATz pin from pulling down when the SoC goes into DeepSleep mode?

Or maybe there is a way to indicate that SoC is in a DeepSleep mode? As an example maybe some GPIO or Power rail is switched off. I could use this signal to block the Reset signal to peripheral devices when the SoC goes into DeepSleep mode.

 On our products, we use the RESET schematic similar to the BeaglePlay Single Board Computer (based on the AM62x SoC).

  • Hello,

    Which SDK version are you using?


    In the AM62x Technical Reference Manual (https://www.ti.com/lit/ug/spruiv7b/spruiv7b.pdf), please see 14.2.1.2 Pad Configuration Registers.

    RESETSTATz's PADCONFIG register is PADCONFIG147 as seen in Table 14-6173. Pad Configuration PADCONFIG Registers.

    Table 14-6172. Description Of The Pad Configuration Register Bits shows that Bits[24:28] of the PADCONFIG register controls the status in Deep Sleep. It should take precedence over any changes the DM Firmware makes. I think toggling Bit24 should be considered.

    If needed, we can loop in the schematics expert to review the Reset implementation or look deeper into the DM Firmware code

    Best Regards,

    Anshu

  • Hello 

    That is the SDK that I use:
    Latest prebuilt SDK images (https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-PvdSyIiioq/09.02.01.09/tisdk-default-image-am62xx-evm.wic.xz)
    Version: 09.02.01.09, Release date: 29 Mar 2024

    During the last few days, I did some measurements and tests trying to understand the details.

    I checked the content of the PADCONFIG Registers for the RESETSTATz and PORz_OUT pins, the value of bit 24 is 0. I also tried to change this value. It didn't help me.

    When I'm initiating a DeepSleep mode the RESETSTATz and PORz_OUT pins are pulled down.

    It is bad for me because it resets all the peripheral devices including eMMMC and it creates an issues when system is recovering from the DeepSleep.

    The results of my measurements are attached below.

    As you can see, all the signals go down in a DeepSleep mode except for the MCU_RESETSTATz.

    I also did the similar tests on the SK-AM62-P1 board and I've been able to reproduce this behavior.

    I measured the EMMC Reset (eMMC_RSTn) and Ethernet PHY Reset (CPSW_RGMII1_RESETn).

    This signals goes down when the DeepSleep mode is initiated and puts eMMC and Ethernet PHY in a reset state.

    Is this what we should expect?

    What is the idea behind it?

    Should the peripheral devices stay in a Reset state when the SoC is in the DeepSleep mode?

    Thank you.

  • Hello,

    The expectation for the PADCONFIG bit 24 set to zero is to maintain the current state.

    Thanks for the information. I'll have to look into this and get back to you.

    Best Regards,

    Anshu

  • Hello,

    As I mentioned in the other thread, I got clarification on bit24. If bit24 is set to zero, then the IO states will carry over from Active state into Deep Sleep. If bit24 is set to one, then the IO states will use what was defined in bits 25-30. This might be a variable to review.

    I think its worth reviewing if the DM firmware will try to influence control over the reset unexpectedly.

    Thanks,

    Anshu

  • Hello,

    Not sure if you are still expecting a response from Anshu. He'll be out for the next couple weeks. If additional followup is needed, he can do that around early to mid July.

    Regards,

    Nick