SPRZ397K November   2012  – September 2024 TDA2EG-17 , TDA2HF , TDA2HG , TDA2HV , TDA2LF , TDA2SA , TDA2SG , TDA2SX

 

  1.   1
  2. 1Introduction
    1.     Related Documentation
    2.     Trademarks
    3.     Modules Impacted
  3. 2Silicon Advisories
    1.     Revisions SR 2.0, 1.1, 1.0 - Advisories List
    2.     i202
    3.     i378
    4.     i631
    5.     i694
    6.     i698
    7.     i699
    8.     i727
    9.     i729
    10.     i734
    11.     i767
    12.     i782
    13.     i783
    14.     i802
    15.     i803
    16.     i807
    17.     i808
    18.     i809
    19.     i810
    20.     i813
    21.     i814
    22.     i815
    23.     i818
    24.     i819
    25.     i820
    26.     i824
    27.     i826
    28.     i829
    29.     i834
    30.     i837
    31.     i840
    32.     i841
    33.     i842
    34.     i843
    35.     i847
    36.     i849
    37.     i852
    38.     i854
    39.     i855
    40.     i856
    41.     i859
    42.     i861
    43.     i862
    44.     i863
    45.     i868
    46.     i869
    47.     i870
    48.     i871
    49.     i872
    50.     i874
    51.     i875
    52.     i878
    53.     i879
    54.     i880
    55.     i882
    56.     i883
    57.     i884
    58.     i887
    59.     i889
    60.     i890
    61.     i893
    62.     i895
    63.     i896
    64.     i897
    65.     i898
    66.     i899
    67.     i900
    68.     i901
    69.     i903
    70.     i916
    71.     i927
    72.     i929
    73.     i930
    74.     i932
    75.     i933
    76.     i936
    77.     i940
    78.     i2446
  4. 3Silicon Limitations
    1.     Revisions SR 2.0, 1.1, 1.0 - Limitations List
    2.     i596
    3.     i641
    4.     i833
    5.     i838
    6.     i844
    7.     i845
    8.     i848
    9.     i850
    10.     i851
    11.     i853
    12.     i857
    13.     i858
    14.     i876
    15.     i877
    16.     i892
    17.     i909
  5. 4Silicon Cautions
    1.     Revisions SR 2.0, 1.1, 1.0 - Cautions List
    2.     i781
    3. 4.1 106
    4.     i827
    5.     i832
    6.     i836
    7.     i839
    8.     i864
    9.     i885
    10.     i886
    11.     i912
    12.     i926
    13.     i931
    14.     i935
  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

SR 2.0, 1.1

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

TDA2x: 2.0, 1.1

DRA75x, DRA74x: 2.0, 1.1

AM572x: 2.0, 1.1