SPRZ429N July   2014  – July 2024 AM5726 , AM5728 , AM5729

 

  1.   1
  2. 1Introduction
    1.     Related Documentation
    2.     Trademarks
    3.     Modules Impacted
  3. 2Silicon Advisories
    1.     Revisions SR 2.0, 1.1 - 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 - Limitations List
    2.     i596
    3.     i641
    4.     i833
    5.     i838
    6.     i845
    7.     i848
    8.     i850
    9.     i851
    10.     i853
    11.     i857
    12.     i858
    13.     i876
    14.     i877
    15.     i892
    16.     i909
    17.     i922
    18.     i925
  5. 4Silicon Cautions
    1.     Revisions SR 2.0, 1.1 - Cautions List
    2. 4.1 106
    3.     i827
    4.     i832
    5.     i836
    6.     i839
    7.     i864
    8.     i885
    9.     i886
    10.     i912
    11.     i926
    12.     i931
    13.     i935
  6. 5Revision History

i698

DMA4 Generates Unexpected Transaction on WR Port

CRITICALITY

Medium

DESCRIPTION

The DMA4 channel generates an unexpected transaction on WR port under the following 2 scenarios:

  • Scenario 1
    1. Software synchronization: Bit fields SYNCHRO_CONTROL and SYNCHRO_CONTROL_UPPER are set to 0 in register DMA4_CCRi
      • Channel element number: Bit field CHANNEL_ELMNT_NBR is set to 0x9 in register DMA4_CENi
      • Channel frame number: Bit field CHANNEL_FRAME_NBR is set to 0x1 in register DMA4_CFNi
      • Element size: Bit field DATA_TYPE is set to 0x2 in register DMA4_CSDPi
      • Destination addressing mode: Bit field DST_AMODE is set to 0x1 in register DMA4_CCRi
      • Destination is packed: Bit field DST_PACKED is set to 0x1 in register DMA4_CSDPi
      • Destination endianism: Bit field DST_ENDIAN is set to 0x0 in register DMA4_CSDPi
      • Destination burst enable: Bit field DST_BURST_EN is set to 0x1 in register DMA4_CSDPi
      • Destination start address: Register DMA4_CDSAi is set to 0xabcd0000
      • Disable graphics operation: Bit fields CONST_FILL_ENABLE and TRANSPARENT_COPY_ENABLE are set to 0x0 in register DMA4_CCRi
      The channel has got an ERR response on the WR port before the end of block transfer. The channel has gone for clean abort and got disabled. The same channel has been configured with soft-sync and included in the channel chaining (This channel is not the head of the chain). When this channel gets enabled through the link, the channel is writing the data out as soon as it fetches the data from Read side. It is expected that the channel should go with burst transfer, but it is going for single transfers.
      This results in a performance issue as DMA is executing single transfers instead of burst transfers. This performance issue is also observed while using the channel with destination synchronization and prefetch enabled.
    2. Destination sync with Prefetch enabled: Bit field SEL_SRC_DST_SYNC is set to 0x0; Bit fields SYNCHRO_CONTROL_UPPER and SYNCHRO_CONTROL should not be set to 0x0; Bit field PREFETCH is set to 0x1 in register DMA4_CCRi. The other settings remain same as in use case #1 described above
  • Scenario 2
    • The channel has got an ERR response on the WR port before the end of block transfer. The channel has gone for clean abort and got disabled. The same channel has been configured with destination-sync with prefetch enabled and included in the channel chaining (This channel is not the head of the chain). When this channel gets enabled through the link, the read port will start its transaction. If the HWR request to this channel comes before the channel gets its first response, the channel will start a WR transaction with byte enable 0. Also, the internal data counters get updated and the corresponding data will never come out of DMA4. The Data FIFO locations are also not recovered.
      This results in a Data Integrity issue.

WORKAROUND

There is a software workaround to solve this issue

  1. Work around to resolve both Data Integrity and Performance issue:
    • Dummy enable-disable for an aborted Channel. i.e. on abort, configure the channel as soft sync with No of frames = 0 and enable the channel by writing 0x1 into the ENABLE bitfield of register DMA4_CCRi. Wait for the Address Misaligment Interrupt. The channel is now ready for reuse.
    • Ensure that clean drain happens for a channel that is or is to be used as part of a channel chain. i.e. ensure that the abort conditions never occur for this channel
    • If a channel gets aborted, do not reuse the channel in a chain
    • Don't use channel chaining
  2. Work around to resolve the data integrity only.
    Disable prefetch in all channels that are part of a channel chain

REVISIONS IMPACTED

SR 2.0, 1.1

TDA2x: 2.0, 1.1, 1.0

DRA75x, DRA74x: 2.0, 1.1, 1.0

AM572x: 2.0, 1.1