• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Queue Error Threshold after running for a long while

Guillermo Fernandez
Intellectual 385 points

Hi experts,

We have almost finished our project using a DM648 but after running without any problem for a long while (24hours, 36hours, 10 hours…) we suffer a program hang. .Looking into the problem we have observed that Queue Error Threshold for Queue 2 is set in CCERR register. We have used MCASP for audio transmission and reception (allocated at Transfer Controller 0), Vport0 for stream reception (configured as Raw mode and it was allocated at Transfer Controller 1), Vport1 for video reception (dual channel BT656 capture and allocated at Transfer Controller 2) and Vport2 for displaying encoded images and QDMA transfers (Transfer Controller 3). QDMA only reads from DDR2 like Vport2. QUEPRI is set to 0x00003210.

The program was trapped in the “edma3CCErrHandler” routine. We can not understand how it is possible that the number of events in QUEUE2 increases suddenly. Could somebody help me?

Thanks in advance.

Best Regards.

 

  • 0
    TI__Mastermind 18320 points

    This doesn't appear to really be a BIOS-based question.  I am going to move this thread to a more appropriate forum in hopes that it will get a quicker response.

     

    Dave

  • 0 in reply to David Friedland
    Intellectual 385 points

    Hi,

    We have looked into the problem a bit more. We obtain unless one underrun error (VPORT2 = QUEUE3) before queue2 threshold error occurs but the watermark for maximum queue2 usage value exceeds the expected value (11 instead of 6) at this point. The expected value for this queue is 6 because we are using dual channel BT656 capture (VPORT1).The watermark for maximum queue 3 usage keeps the expected value (3) when underrun error appears. If we run the program after that underrun error the program will trap at “edma3CCErrHandler” routine and queue3 threshold error also appears.

    Anyway, the reason for "The program was trapped in the “edma3CCErrHandler” routine" it is that we can not clear the value of CCERR and the ISR is called continuously.

    I do not understand how it is possible, any idea about it?

    Thank you.

    Best Regards.

     

     

     

  • 0 in reply to Guillermo Fernandez
    TI__Expert 5750 points

     

    Looking description, it looks like after long  hours of run, the errors manifest. this is because of cumulative effect  of misses /delays/underrun in the system, which manifest.

     

    Since this is very specific to your application, I can only make a few suggestions below : 

    1. change the ‘QUEPRI’ register to give higher priority to the TC3, TC2.
    2. Use EDMA self-chaining without CPU intervention – if possible
    3. have audio buffers in internal memory if not already there.
    4. tweak the MSTPRI registers.
    5. EMIF command re-ordering. PBBPR register. What is its current value ? 0x20 is commonly used value.
    6. Bump up EDMA read rate (RDRATE register). Refer EDMA user guide.

     

     Hope this helps.

     

  • 0 in reply to Varada Bellary
    TI__Expert 8260 points

    Guillermo Fernandez,

    Also check this old post and see if the recommendataions in this post helps to resolve this issue:

    http://e2e.ti.com/support/embedded/f/354/t/60398.aspx 

    Regards, Srirami.

  • 0 in reply to srirami
    Intellectual 385 points

    Thank you for your replies and i want to apologize for the delay in my response.

    1. change the ‘QUEPRI’ register to give higher priority to the TC3, TC2.

    It does not solve our problem.

    1. Use EDMA self-chaining without CPU intervention – if possible

    It is not possible in our aplication.

    1. have audio buffers in internal memory if not already there.

    We can not do it because of Chip Errata related to SDMA.

    1. tweak the MSTPRI registers.

    We did it and it did not solve our problem.

    1. EMIF command re-ordering. PBBPR register. What is its current value ? 0x20 is commonly used value.

    Our current value is 0x10. If we change this value to 0x20 MCASP suffer underrun and overrun problems.

    1. Bump up EDMA read rate (RDRATE register). Refer EDMA user guide.

    We have modified this value and we do not observe any improvement.

     

    Thank you Srirami for your reply, this post was set by me a few months ago for other problem. This post has been helpful for us because it remind us other Transfer Controller distribution possibilities.

     

    We have solved our problem modifying the distribution of our EDMA transfers in different TCs. The current configuration is:

     

    TC0: MCASP Rx/Tx

    TC1: QDMA

    TC2: VP1A/VP1B and VP0 (for transport stream reception)

    TC3: VP2

     

    Thank you very much for your help.