SPRZ452I july   2018  – may 2023 AM6526 , AM6528 , AM6546 , AM6548

 

  1. 1Usage Notes and Advisories Matrices
  2. 2Nomenclature, Package Symbolization, and Revision Identification
    1. 2.1 Device and Development-Support Tool Nomenclature
    2. 2.2 Devices Supported
    3. 2.3 Package Symbolization and Revision Identification
  3. 3Silicon Revision 2.1, 2.0, 1.0 Usage Notes and Advisories
    1. 3.1 Silicon Revision 2.1, 2.0, 1.0 Usage Notes
      1. 3.1.1 Fail-Safe IO's: Latch-up Risk on Fail-Safe IOs
      2. 3.1.2 ADC: High Input Leakage Current May Impact ADC Accuracy
      3. 3.1.3 INTRTR: Spurious Interrupts Generated when Programming Certain Interrupt Routers
      4.      i2351
    2. 3.2 Silicon Revision 2.1, 2.0, 1.0 Advisories
      1. 3.2.1 Silicon Revision 2.1, 2.0, 1.0 Advisory List
      2.      i939
      3.      i2000
      4.      i2004
      5.      i2006
      6.      i2009
      7.      i2013
      8.      i2015
      9.      i2018
      10.      i2019
      11.      i2020
      12.      i2021
      13.      i2022
      14.      i2023
      15.      i2024
      16.      i2025
      17.      i2026
      18.      i2027
      19.      i2028
      20.      i2030
      21.      i2032
      22.      i2037
      23.      i2038
      24.      i2039
      25.      i2046
      26.      i2053
      27.      i2054
      28.      i2055
      29.      i2068
      30.      i2069
      31.      i2073
      32.      i2075
      33.      i2076
      34.      i2083
      35.      i2084
      36.      i2095
      37.      i2096
      38.      i2097
      39.      i2098
      40.      i2099
      41.      i2101
      42.      i2103
      43.      i2104
      44.      i2106
      45.      i2115
      46.      i2116
      47.      i2118
      48.      i2119
      49.      i2129
      50.      i2132
      51.      i2137
      52.      i2138
      53.      i2139
      54.      i2141
      55.      i2143
      56.      i2146
      57.      i2148
      58.      i2149
      59.      i2161
      60.      i2162
      61.      i2164
      62.      i2165
      63.      i2177
      64.      i2184
      65.      i2185
      66.      i2187
      67.      i2189
      68.      i2193
      69.      i2196
      70.      i2198
      71.      i2204
      72.      i2207
      73.      i2231
      74.      i2234
      75.      i2245
      76.      i2307
      77.      i2014
      78.      i2145
      79.      i2163
      80.      i2173
      81.      i2249
      82.      i2278
      83.      i2279
      84.      i2307
      85.      i2310
      86.      i2311
      87.      i2320
      88.      i2328
      89.      i2329
      90.      i2040
      91.      i2041
      92.      i2043
      93. 3.2.2 i2151
      94.      i2262
      95.      i2264
      96.      i2265
      97.      i2266
      98.      i2268
      99.      i2312
      100.      i2371
        1.       Trademarks
          1.        Revision History

i2006


UDMA-P: UDMA-P Real-Time Remote Peer Registers not Functional Across UDMA-P Domains

Revision(s) Affected:

AM65x SR 1.0

Details:

In the UDMA-P, both RX and TX channels contain a specific set of registers called “Real-time Remote Peer Registers” (UDMA_PEER[0-15]_j registers). These registers provide access to the remote peer device’s real time registers within the PSI-L configuration (PSIL_CFG) register space, address 0x400 to 0x40F. The peer device is the device that the UDMA-P channel is communicating with, and is set via the Rx/TX Channel Destination Thread ID Mapping Register (UDMA_THREAD_j register). Once the UDMA_THREAD_j register is configured with the peer’s PSI-L thread ID, any access to the UDMA_PEER[0-15]_j registers on the UDMA-P will results in an access to the PSI-L register on the peer corresponding to the offset of the register accessed. For example, peer register 0 maps to peer PSI-L address 0x400, and peer register 1 maps to peer PSI-L address 0x401, and so on. Having these registers allows the UDMA-P driver to access peer registers in the 0x400 to 0x40F range without accessing the configuration proxy IP, which in some environments can be reserved for secure access only.

There are two UDMA-P instances on the device. These instances exist in separate domains called MAIN and MCU. Along with the two UDMA-P instances, individual peripheral devices also reside in both domains. It was originally intended that a UDMA-P instance in one domain would seamlessly work with a peripheral in the other domain. For the most part, this is still the case, but when it comes to using the peer registers, a bug in the internal message routing prevents the UDMA-P peer registers in the MAIN domain from accessing the PSI-L registers of a peripheral in the MCU domain, and prevents the UDMA-P peer registers in the MCU domain from accessing the PSI-L registers of the peripheral in the MAIN domain. Read results across UDMA-P domains will always be invalid. Writes across UDMA-P domains will still take affect but will take longer than normal.

Workaround(s):

Avoid using the UDMA-P peer registers in one domain to access PSI-L registers of a peripheral in the other domain. This can be accomplished in one of two ways:

  1. Always allocate a TX/RX channel from the UDMA-P residing in the same domain as the target peripheral.
  2. Use the PSI-L proxy module to write PSI-L registers 0x400 through 0x40F instead of the using the UDMA-P Real-time Remote Peer registers.

Solution 1 avoids the problem by making sure that the peer register access is never performed “across domains.”

Solution 2 avoids the problem by not making use of the affected registers. The drawback here is that in some environments the PSI-L proxy module is restricted to secure access only. This means that any register access will have to be done through secure code, increasing overhead.

Note, solution 1 is preferred due to secure access limitation for this resource configuration when implementing the workaround in software.