SPRZ450B February   2018  – September 2024 DRA74P , DRA75P , DRA76P , DRA77P

 

  1.   1
  2. 1Introduction
    1.     Related Documentation
    2.     Trademarks
    3.     Modules Impacted
  3. 2Silicon Advisories
    1.     Revisions SR 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.     i869
    36.     i870
    37.     i871
    38.     i872
    39.     i874
    40.     i878
    41.     i879
    42.     i883
    43.     i889
    44.     i890
    45.     i893
    46.     i896
    47.     i897
    48.     i898
    49.     i899
    50.     i900
    51.     i903
    52.     i904
    53.     i916
    54.     i929
    55.     i930
    56.     i932
    57.     i933
    58.     i936
    59.     i940
    60.     i2446
  4. 3Silicon Limitations
    1.     Revisions SR 1.0 - Limitations List
    2.     i596
    3.     i641
    4.     i833
    5.     i838
    6.     i844
    7.     i845
    8.     i848
    9.     i876
    10.     i877
    11.     i892
    12.     i909
  5. 4Silicon Cautions
    1.     Revisions SR 1.0 - Cautions List
    2.     i781
    3.     i827
    4.     i832
    5.     i836
    6.     i839
    7.     i864
    8.     i885
    9.     i886
    10.     i912
    11.     i926
    12.     i931
    13.     i935
    14.     i937
  6. 5Revision History

i862

Reset Should Use PORz

CRITICALITY

High

DESCRIPTION

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 my 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.

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

This erratum is fixed on DRA75xP, DRA74xP, DRA77xP, DRA76xP SR 1.0. However, the i862 workaround may still be required for some use cases. Refer to i727 and i729 for more details.

AM574x: 1.0

DRA75xP, DRA74xP, DRA77xP, DRA76xP: 1.0

TDA2Px: 1.0

AM576x: 1.0