• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 480 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

AM6442: Retain GPIO state through a Warm Reset

Jason Reeder
Genius 10440 points
Part Number: AM6442

TRM states that 'IOs are not effected' in the main domain during a warm reset (section 5.3.5.2.3 SW_MAIN_WARMRSTz Reset).

However, when I set a GPIO to output low and then trigger a SW warm reset, when I stop the device at the U-Boot prompt I can see that the GPIO has been reset to an input which causes the signal on my logic analyzer to be pulled high (there is a pull-up resistor on the signal).

I need the signal to stay low, despite the pull-up to 3.3V, through a warm reset. Is this possible?

  • 0
    TI__Mastermind 45746 points

    Hello Jason,

    Can you please confirm whether the reset isolation patch (isolating the MCU core from the main domain) is included in your application or not?

    What is the use case here? Why did you want to keep the GPIO singal as low as possible at all times in both Application and Boot time ? Are you controlling any critical device

    through this GPIO pin?

    To better assist you, I need the above information.

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    I am using the Linux RT release with no modifications so I'm assuming the reset isolation patch is not there. Can you point me to more information about this patch?

    The use case is that the AM64x is controlling the reset pin of other devices in the overall system. When the AM64x unexpectedly shuts down (watchdog timer or otherwise), or goes through a firmware update warm reset, we'd like to keep the reset pin in a known state.

    The TRM states that IO's in the main domain are not affected by a warm reset but I'm seeing the GPIO registers switch to all inputs when I stop the boot at the u-boot prompt.

    If this is only possible through the MCU domain with reset isolation can you point me to an example to showcase this?

  • 0 in reply to Jason Reeder
    TI__Mastermind 45746 points

    Hello Jason,

    Jason Reeder said:
    I am using the Linux RT release with no modifications so I'm assuming the reset isolation patch is not there. Can you point me to more information about this patch?
    Jason Reeder said:
    The TRM states that IO's in the main domain are not affected by a warm reset but I'm seeing the GPIO registers switch to all inputs when I stop the boot at the u-boot prompt.

    Thanks for giving full information.

    I am asking about whether the customer already has integrated isolation software (isolating the MCU core from the main domain) or not, based on the

    above comments. I think they have not included isolation software in their application.

    MAIN domain IO's are not affected - > This is possible by only isolating the MCU core from the MAIN  domain, and I should also get info from the design

    engineer on what the exact meaning of IO's is, whether it is GPIO's or any peripherals.

    Jason Reeder said:
    If this is only possible through the MCU domain with reset isolation can you point me to an example to showcase this?

    Yes, your understanding is correct. It is possible with reset isolation.

    Jason Reeder said:
    The use case is that the AM64x is controlling the reset pin of other devices in the overall system. When the AM64x unexpectedly shuts down (watchdog timer or otherwise), or goes through a firmware update warm reset, we'd like to keep the reset pin in a known state.

    This use case can be achieved with the reset isolation method. You can configure the MCU GPIO pin to control external devices from the MCU domain.

    So,  when  any Resets happen due to watchdogs or other reasons, and the reset path is not propagated through the MCU domain. So that your MCU

    domain will hold  previous status . If POR occurs, your external devices will be affected.

    Please check Reset isolation examples are available at the below link.

    C:\ti\mcu_plus_sdk_am64x_08_06_00_43\examples\drivers\safety\reset_isolation

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    S.Anil,

    Swargam Anil said:

    MAIN domain IO's are not affected - > This is possible by only isolating the MCU core from the MAIN  domain, and I should also get info from the design

    engineer on what the exact meaning of IO's is, whether it is GPIO's or any peripherals.

    'Main domain IO's are not affected' seems pretty clear from the TRM section about warm resets. I don't see how isolating the MCU core will have anything to do with the Main domain IO's. Can you confirm what the TRM means in the warm reset sections when it says 'Main domain IO's are not affected?

  • 0 in reply to Jason Reeder
    TI__Mastermind 45746 points
    Jason Reeder said:
    'Main domain IO's are not affected' seems pretty clear from the TRM section about warm resets. I don't see how isolating the MCU core will have anything to do with the Main domain IO's. Can you confirm what the TRM means in the warm reset sections when it says 'Main domain IO's are not affected?

    Hello Jason,

    I have the doubt: if we set up the MCU domain as isolated from the main domain, then MCU GPIO's should be isolated from the reset; then how are the

    main GPIO's not affected? and IO's means - > it should come GPIO's and peripherals that I should confirm with the design team. I will send mail to the design team

    today and update the status once I have received a reply from them.

    Regards,

    S.Anil.

  • +1 in reply to Swargam Anil
    TI__Mastermind 45746 points

    Hello Jason,

    I got reply from the design Team as below 

    " IO here 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 Main domain gets a warm reset event, it

    will reset the GPIO module. If you previously configured GPIO module as an output it will go back to reset state (which is input) "

    So, based on the above comments , the GPIO pin does not hold the previous status after the warm reset, and to achieve not disturbing GPIO pins after

    the warm reset, you have to go with the MCU GPIO and MCU Reset Isolation method.

    I hope this helps your query .

    Regards,

    S.Anil.

  • 0 in reply to Swargam Anil
    TI__Genius 10440 points

    S.Anil,

    Thanks for checking with the design team. GPIO peripheral reverting back to input (default state) on a warm reset matches my observation.

    Jason