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.

C6424 EDMA Bus error

Hi,

I have a custom board, and I have an issue with EDMA transfer.

Actually, in a dedicated task, I am using McBSP and EDMA to get samples from an ADC.

It works quite well during a certain amount of time (non constant), but after a while my task stops and when I check the registers I see that for EDMA ERRSTAT->BUSERR is set to 1.

And ERRDET->STAT is set to 1 meaning that there is a "read adressing error" (for the McBSP, SPCR->RFULL can also be set to "1" : synonym of overrun error according to SPRUEN2B.pdf.)

 

Do you have any suggestions in order to solve this problem?

 

Best Regards,

 

Simon

 edit:  Actually It seems that ERRDET->STAT is set to 1 even directly after I load my program and even when the acquisition on the ADC is still OK ???

  • Hi,

    Thanks for your post.

    Actually, RFULL = 1 in the serial port control register (SPCR) indicates the overrun error condition and there are few possibilities described below to met this condition:

    1.  DRR would have not been read since the last RBR-to-DRR transfer

    2. RBR is full and a RBR-to-DRR copy wouldn't have occured

    3. RSR is full and a RSR-to-RBR transfer also have not occured.

    Basically, if DRR is not been read by the CPU or the EDMA controller since the last RBR-to-DRR transfer (RRDY = 1), an RBR-to-DRR copy would not take place until RRDY = 0. and this prevents an RSR-to-RBR copy. New data arriving on the DR pin would be shifted into RSR, and the previous contents of RSR would have been lost and there results a receive overrun issue which sets the RFULL to 1. Kindly evaluate the above condition and validate the error condition as you suspect.

    In order to allow for subsequent transfers to be read properly, you could clear the RFULL bit to 0 through executing the below events:

    • Reading DRR
    • Resetting the receiver (RRST = 0) or the device and always, another frame sync. is needed to restart the receiver

    Also, please validate the initialization procedure as mentioned in section 2.11.1 in McBSP user guide (SPRUEN2B.pdf) and ensure all the steps have been properly taken care in the code.

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question

    -------------------------------------------------------------------------------------------------------

  • Simon,

    The ERRSTAT.BUSERR setting is unfortunately vague. It implies you tried to read from an invalid address or something failed to accept the read command internally. The only thing I can think of that would lead to an addressing error for the McBSP is having an invalid address in your SRC field of the PARAM for the transfer.

    You will generally see RFULL=1 when something causes the EDMA to stop servicing McBSP events. Since the data is still coming in, an overrun will always happen. This is a symptom of the problem and not a reason for the problem.

    You can look at other TC error and status registers, and look at the Source Active registers and the Destination FIFO registers. You can try to figure out what the last transfer was that was successful and where the final transfer was in its process when the failure occurred. Of course, this assumes the TC was not doing other transfers for your application after this.

    The documentation for these TC error and status registers are in the EDMA3 User's Guide. You may want to learn them by watching how they operate during good operation so you can compare when the failure occurs. This is advanced debugging and is not something that can be done well remotely.

    The most common cause of McBSP + EDMA3 problems is not having enough time for the EDMA3 to service the events from the McBSP. The speed of the McBSP and the word size of the transfers will contribute to this (fast and small size leave less time between events), and other tasks using the same TC for other things will also contribute to this problem, as will conflict stalls at the destination (like external memory). You can try lowering the clock of the McBSP to see if the failures go away. Or you can try reducing other system activity or moving other transfers to another TC. And you can try changing the destination to an internal address.

    Some ideas, at least.

    Regards,
    RandyP

  • Hi Randy,

     

    First of all thank you for your reply.

    To give you a little bit more information:

    I also check some other registers EMR, EMRH, EMCRH, EMCR, CCERR which are all set to 0.

    If there is almost not activity except the signal acquisition on the ADC (no processing of the signal at all), I don't see the problem.

    I tried to reduce the McBSP clock but it doesn't seem to help.

    I am using PSP driver (1.10.03) and edma3_lld_01_10_00_01.

    I am using a GIO_submit function  but certainly as a consequence of an  "EDMA  problem" (waiting for a kind of EDMA completion interrupt?)  it stucks in here because my callback function is not called.

    Maybe these informations can help you advising me on my problem?

    Thanks again for your help.

    Regards,

     

    Simon

    PS: sorry for my English...