• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 97 subscribers
  • Views 272 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.

the RX clock and FS of Mcasp has offset after engine_open() is called

golden tiger
Intellectual 625 points

Dear All:

    Mcasp(TDM)  has 32 slots  and a slot is 8 bits wide.  The FS  is  8K  HZ  and RX bit clock  is  2M  HZ. In the begining, the FS  is   synchronous  with  first  bit clock of RX bit clock.

   When  engine_open() is called ,  the mcasp data  is wrong.   The first slots data go into 3th or other slot.  It means that  FS  is asynchronous  with RX bit clock.

  There is offset between FS  and  RX  bit clock. 

  The mcasp work by EDMA  in arm.

  • 0
    TI__Expert 4245 points

    Hi,

    Can we have some more information? Which device are you using and which SDK or PSP version do you see this problem with?

  • 0 in reply to Siddharth Heroor
    Intellectual 625 points

    Quote:

         SDK  is  EZSDK-5.02 and PSP is linux-2.6.37-psp04.00.00.12. The platform is CA8168.  Today, I find that ROVRN bit of RSTAT  register of Mcasp is set to 1  if  RX data is wrong.  It means that receiver overrun.

        I don't know why engine_open() can effect the Mcasp?

       Can I avoid the wrong event  after  engine_open() is called?

     

     

    Thanks

  • 0 in reply to golden tiger
    TI__Expert 4245 points

    Its possible that the DSP image that you have is writing to McASP registers. Can you please check the memory map and ensure that there are no stray memory accesses?

  • 0 in reply to Siddharth Heroor
    Intellectual 625 points

    Hi:

       I  think that  DSP image  don't  write McASP registers.  Moreover,  the  RX  and TX  of  McASP  have  the  same  underrun/overrun error  when  Hard Disk  read  or  write  large block  data.

       I  think  that  operation  of  hard disk  effect  the  EDMA  of McASP.   It  results that  EDMA  of  McASP  stop to  read/write  data.

       I suspect some kind of race condition is resulting in underrun/overrun  error, but  I am not able to pin point the root cause.

       The hard disk  don't  transfer data by EDMA.

       I  modify the priority  of  EDMA  queue, but it  has no effect.

       But I don't  know  why  the hard disk  can effect  the  McASP?

       How  can  I   eliminate  the  effect?

     

    Thanks