SPRZ436H October   2015  – July 2024 AM5706 , AM5708 , AM5716 , AM5718 , AM5718-HIREL

 

  1.   1
  2. 1Introduction
    1.     Related Documentation
    2.     Trademarks
    3.     Modules Impacted
  3. 2Silicon Advisories
    1.     Revisions SR 2.1, 2.0, 1.0 - Advisories List
    2.     i202
    3.     i378
    4.     i631
    5.     i694
    6.     i698
    7.     i699
    8.     i709
    9.     i727
    10.     i729
    11.     i734
    12.     i767
    13.     i782
    14.     i783
    15.     i802
    16.     i803
    17.     i807
    18.     i808
    19.     i809
    20.     i810
    21.     i813
    22.     i814
    23.     i815
    24.     i818
    25.     i819
    26.     i820
    27.     i824
    28.     i826
    29.     i829
    30.     i834
    31.     i849
    32.     i856
    33.     i862
    34.     i863
    35.     i867
    36.     i868
    37.     i869
    38.     i870
    39.     i871
    40.     i872
    41.     i874
    42.     i875
    43.     i878
    44.     i879
    45.     i880
    46.     i882
    47.     i883
    48.     i887
    49.     i889
    50.     i890
    51.     i893
    52.     i895
    53.     i896
    54.     i897
    55.     i898
    56.     i899
    57.     i900
    58.     i903
    59.     i904
    60.     i906
    61.     i907
    62.     i913
    63.     i916
    64.     i927
    65.     i928
    66.     i929
    67.     i930
    68.     i932
    69.     i933
    70.     i936
    71.     i940
    72.     i2446
  4. 3Silicon Limitations
    1.     Revisions SR 2.1, 2.0, 1.0 - Limitations List
    2.     i596
    3.     i641
    4.     i833
    5.     i838
    6.     i845
    7.     i848
    8.     i876
    9.     i877
    10.     i892
    11.     i909
    12.     i922
    13.     i925
  5. 4Silicon Cautions
    1.     Revisions SR 2.1, 2.0, 1.0 - Cautions List
    2.     i827
    3.     i832
    4.     i836
    5.     i839
    6.     i864
    7.     i885
    8.     i886
    9.     i912
    10.     i918
    11.     i920
    12.     i921
    13.     i926
    14.     i931
    15.     i934
    16.     i935
  6. 5Revision History

i862

Reset Should Use PORz

CRITICALITY

High

DESCRIPTION

On SR 1.0, Power-on-reset (porz SoC input signal) is the only 100% reliable reset type. If any reset source other than porz is used, there is a chance the SoC may hang during boot after the reset source is de-asserted. Examples of other reset sources include software resets (global cold, global warm), hardware exception resets (Watchdog, Thermal Shutdown, Security violations), or the Warm Reset input (resetn SoC input). Entry into reset will be successful with these reset sources, but code execution may hang if reset is initiated by any reset source other than porz.

Two examples: A watchdog reset will indicate a runaway code event has occurred by resetting the SoC and asserting rstoutn. A thermal shutdown reset (TSHUT) will reset the SoC and assert rstoutn which prevents the SoC from overheating. However, code execution may hang when the SoC attempts to reboot from any source other than porz (including a watchdog and thermal shutdown reset).

Power-On-Reset (porz SoC input) is 100% reliable and can recover from the SoC hang. On SR 2.1 and SR 2.0, all reset types can be used. However, some use cases may still require the workaround described by this erratum. Refer to i727 and i729 for more details.

WORKAROUND

PORz should be used for all reset occurrences.

Two recommended implementations are provided below. Note: All reset sources will assert reset to the system via the SoC rstoutn output. This allows external visibility to software or watchdog resets, which would otherwise be invisible to components outside of the SoC. Both recommended implementations will use the rstoutn output.

Implementation 1: PMIC asserts porz when rstoutn is connected to PMIC NRESWARM input

  • When the rstoutn output from the SoC is connected to the external PMIC's NRESWARM input, the PMIC companion device approved for use with the SoC can be configured to detect the rstoutn/NRESWARM assertion and assert porz/RESET_OUT. All PMIC companion devices which have been approved for the SoC implement this feature. The feature is bootstrap selectable via one of the PMIC's BOOT pin(s). Refer to PMIC User Guide for additional details. Note: This implementation option has no added cost to the customer since the SoC must be used with one of the approved PMIC devices.
  • To implement the workaround:
    • Connect the rstoutn output from the SoC to the PMIC's NRESWARM input (and to any other components that need to reset when the SoC undergoes a reset). Note: When the rstoutn output is operating in 3.3V mode, a 3.3 volt to 1.8 volt level translator will be required to level shift the rstoutn output connected to the PMIC’s NRESWARM input to 1.8 volts.
    • Pull-up the appropriate PMIC BOOTx pin, to configure the PMIC’s RESET_OUT to assert porz on warm reset.
    • The PMIC’s POWERHOLD (GPIO7) input must be pulled high.
  • Example use cases for this implementation include:
    • A switch connected to the PMIC’s POWERHOLD input is used to turn the board on/off.
    • The PMIC applies power to the SoC as soon as the board is powered when the POWERHOLD input is tied high to an always-on supply LDOVRTC_OUT.
    • The PMIC applies power to the SoC once the PWRON input is pulled low by pressing a normally open push-button switch when the POWERHOLD input is pulled high by one of the supplies enabled during device start-up.
  • The side effects/risks of this implementation include:
    • This implementation does not allow software to shut down the PMIC outputs that power the SoC. Only the PMIC RESET_IN can shut down the PMIC outputs while POWERHOLD is pulled high.
    • Risk of exceeding the 200 hour limit defined by Advisory i863, if the PMIC applies power with eMMC in contention longer than 200 hours.

Implementation 2: Additional circuit implemented that generates porz without PMIC support

  • This implementation enables software shutdown of the PMIC since the PMIC’s POWERHOLD input remains low during operation.
  • To implement the workaround:
    • Pull-down the appropriate PMIC’s BOOTx input.
    • Use an external circuit that generates a finite length active low pulse to porz when the circuit detects the assertion of rstoutn. This feedback path from rstoutn through the pulse generating circuit to porz insures any reset source other than porz generates a valid reset for the SoC.
  • Example use cases for this implementation include:
    • A normally open push button switch (on the system board) connected to the PMIC’s PWRON input is used to initiate PMIC applying power to the device.
    • Software writes to the PMIC registers to power off the device.
  • The benefits/side effects of this implementation include:
    • This implementation allows software to shut down the PMIC since the PMIC’s POWERHOLD input remains low during operation.
    • Reduces the risk described in Advisory i863. This implementation will automatically shut-off power to the SoC seven seconds after the PMIC’s PWRON event unless software writes to appropriate registers to remove contention from the eMMC signals before writing to appropriate PMIC registers that allows the SoC to remain powered.

Other implementations are also possible. For instance, an external watchdog timer could be implemented to assert porz when the SoC becomes unresponsive.

In general, any valid workaround that generates a porz whenever any reset is initiated has the following side effects:

  • Reset status information is lost in PRM_RSTSTAT register.
    • Visibility into the cause of the last reset is lost. To maintain some visibility software may be able to store information in PMIC BACKUP or other PMIC registers.
  • Ethernet Reset isolation feature is not supported.
  • Boot device reordering on warm reset is not supported.

The workaround has the advantage of guaranteeing the entire SoC is in a known good and consistent state for every reboot. For example, there are no software residual effects due to watchdog warm reset.

REVISIONS IMPACTED

AM571x SR 1.0
This erratum is fixed on AM571x SR 2.0 and SR 2.1, and AM570x SR 2.0 and SR 2.1. However, the i862 workaround may still be required for some use cases. Refer to i727 and i729 for more details.

DRA79x: 2.0

TDA2Ex (23mm): 2.0, 1.0

TDA2Ex (17mm): 2.1, 2.0

AM571x: 2.1, 2.0, 1.0

AM570x: 2.1, 2.0

DRA72x: 2.0, 1.0

DRA71x: 2.1, 2.0