This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x McASP AFIFO issue

Hi,

We have encountered problem to using the McASP of AM335x.
When the system is heavily loaded, Output data of McASP be lost by using the AFIFO and EDMA.

Configuration details:
 McASP
   - 4 serial output
 - 8 bit burst transfer mode
  - Use AFIFO(WNUMEVT=4、WNUMDMA=4)

 EDMA(PaRAM configuration)
  EDMA BaseAddress+0x4100
    (OPT) : 0x80100004
    (SRC) : 0x8C638E80
    (BCNT|ACNT) : 0x00040001
    (DST) : 0x46000000
    (DSTBIDX|SRCBIDX) : 0x00000020
    (BCNTRLD|LINK) : 0x0000FFFF
    (DSTCIDX|SRCCIDX) : 0x00000001
    (Rsvd|CCNT) : 0x00000020


We experimented by preparing the output data of the following fixed values.
1byte x 32frame x 4serial port = 128byte output data

(Serial Port0[MCA0_AXR0]): 0x00, 0x01, 0x02, 0x03, ... 0x1C, 0x1D, 0x1E, 0x1F
(Serial Port1[MCA0_AXR1]): 0x20, 0x21, 0x22, 0x23, ... 0x3C, 0x3D, 0x3E, 0x3F
(Serial Port2[MCA0_AXR2]): 0x40, 0x41, 0x42, 0x43, ... 0x5C, 0x5D, 0x5E, 0x5F
(Serial Port3[MCA0_AXR3]): 0x60, 0x61, 0x62, 0x63, ... 0x7C, 0x7D, 0x7E, 0x7F


When the system is NOT heavily loaded, the above data are output correctly from each serial port.
However when the system is heavily loaded, Not correctly data output from the serial port by missing the part of the data.
For example, each serial port output the following data at a problem occurs in the second frame.

                                                    1frame       2frame           3frame   4frame  ...  29frame  30frame   31frame   32frame
(Serial Port0[MCA0_AXR0]):   0x00,  No data output,   0x21,     0x22,    ...    0x3B,       0x3C,      0x3D,        0x3E
(Serial Port1[MCA0_AXR1]):   0x20,  No data output,   0x41,     0x42,    ...    0x5B,       0x5C,      0x5D,        0x5E
(Serial Port2[MCA0_AXR2]):   0x40,  No data output,   0x61,     0x62,    ...    0x7B,       0x7C,      0x7D,        0x7E
(Serial Port3[MCA0_AXR3]):   0x60,  No data output,   0x02,     0x03,    ...    0x1C,       0x1D,      0x1E,        0x1F


EDMA is not a transfer error condition, the problem does not occur when not using the AFIFO even when the system is heavily loaded.
so, we think the AFIFO has H/W issue.


We found a similar problem in the AM437x errata.

[Advisory 16 McASP: McASP to EDMA Synchronization Level Event Can Be Lost(SPRZ408B)]

Does this errata also applies to AM335x?


Best regards,
H.U

  • Hi,

    Please post what Linux version you are using. AM437X Errata does not apply for AM335X.

  • Hi, Biser

    We does not use Linux, we are using ITRON (RTOS).

    Best regards,
    H.U
  • Sorry, I don't see how we can help here. This forum supports only the TI distributed Linux SDK. Perhaps you should turn to this third-party for support on this.

  • Biser Gatchev-XID said:
    Please post what Linux version you are using. AM437X Errata does not apply for AM335X.

    This is not correct. Just received feedback from the factory team that this Errata applies both for AM437X and AM335X. The AM335X Errata will be updated with this in the next release.

  • Is the AFIFO loaded with data before the McASP is started?

  • Hi, Biser

    Thank you for your reply.

    Is the problem that we have encountered due to this errata?
    This errata is described that "the event is cleared but is not re-asserted to the EDMA."
    AFIFO has lost only 1 word in our case, and it seems that EDMA event(EDMA write to AFIFO) is not blocking.

    Best regards,
    H.U

  • Hi H.U-san
    From the problem you have described in the thread above, this does not appear to be Advisory 16.
    Advisory 16 will cause the EDMA to loose an event, and requires manually triggering the McASP channel or reconfiguring the transfers. In your case it appears that you have data loss but the McASP /EDMA is still running, so it is not the failure signature of Advisory 16.

    However the recommendations in the workaround section are all good ones, that might help , even if this purely a bandwidth issue where in EDMA latency to service McASP is higher due to other traffic in your system
    1) Increasing fifo threshold
    2) Isolating McASP buffers in a memory that is less frequently used by other masters
    3) Using the EDMA TC that is used to service McASP being used exclusively for McASP DMA transfers
    are all good suggestions to try to mitigate issues that might be due to traffic contention.

    Regards
    Mukul
  • H.U said:

                                                        1frame       2frame           3frame   4frame  ...  29frame  30frame   31frame   32frame
    (Serial Port0[MCA0_AXR0]):   0x00,  No data output,   0x21,     0x22,    ...    0x3B,       0x3C,      0x3D,        0x3E
    (Serial Port1[MCA0_AXR1]):   0x20,  No data output,   0x41,     0x42,    ...    0x5B,       0x5C,      0x5D,        0x5E
    (Serial Port2[MCA0_AXR2]):   0x40,  No data output,   0x61,     0x62,    ...    0x7B,       0x7C,      0x7D,        0x7E
    (Serial Port3[MCA0_AXR3]):   0x60,  No data output,   0x02,     0x03,    ...    0x1C,       0x1D,      0x1E,        0x1F

    So what is it that you actually see on the bus where you wrote "No data output"?  Zero?

    H.U said:

    [Advisory 16 McASP: McASP to EDMA Synchronization Level Event Can Be Lost(SPRZ408B)]

    Does this errata also applies to AM335x?

    I'm glad you mentioned this item so that we can add it to the AM335x errata as well.  Thank you.  However, I agree with Mukul's assessment that the behavior does not match this errata...  In particular, if an event to the EDMA gets lost then you end up with deadlock, i.e. the EDMA is perpetually waiting to get another event while the McASP AFIFO never sends another event because of its event pacing logic.  So in this scenario the McASP would underflow and the only way to recover is to completely reconfigure the entire McASP.  This is completely different from the behavior you're observing.  It looks to me like you're getting an "extra" sample some how.

    In my opinion the next step is to carefully inspect power and clocking to make sure there's not something marginally out of specification.  That's generally the cause of these unexplained behaviors.  So specifically:

    1. Please put a scope on vdd_core as close as you possibly can to the processor (e.g. on a via under the processor would be great).  Assuming you're running the CORE domain at OPP100 that means you should not dip below 1.056V.  Please report back the measured voltage.  Also please try an experiment where you set the trigger point around that level and see if it ever triggers when you reproduce the issue.
    2. Please attach the rd1 file by using the procedure detailed here:

    On a related note, do you see this issue consistently on all units or are some more susceptible than others?  Have you tested at low or high temperature to see if it affects the occurrence?

  • Is the AFIFO loaded with data before the McASP is started?


    You have not answered this question.