• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 751 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AIF2 in C6670 , RX loss symbols sometime

zi yang
Intellectual 300 points

Hi , TI engineers, please help me with my problem.

I'm using C6670 AIF2 module, and now most parts are running well,  my environment is: CPRI, LTE FDD 20MHZ, 2AxC.

With Tx I'm using 1ms AT event and push 14 symbols into every AxC, it works well.

Rx I'm using PDSP, pdsp will trigger 1 event when it recv 14 symbols, so I should receive 0..13,  14..27, ....., 126..139. every times. and it works fine most times.

But after the system run for a while, the rx side may lost a symbol,  the PDSP event will gave me symbol (0..9, 11-14) and the symbol 10 is missing.  And then I use the CCS to watch the PDCP ping/pong buf, I can fild the pointers are actually discontinue, which means when the pdsp pop from the AIF2 rx queue, the symbol has already missing.

Thanks for watching my question and hope for you advice.  

 

  • 0
    TI__Expert 4740 points

    Hi,

    That means AIF2 Rx lost symbol packet 10 from some reasons below.

    1. incoming frame signal quality is not good, so the symbol was considered as failed. you need to check the quality of the Rx CPRI frame synchronization and signal quality from FPGA or Radio head. AIF2 EE error check will be helpful in this case.

    2. if you always lose only symbol 10 (for example), that is not a signal quality problem. you should check the FPGA or RH module symbol programming.

    3. to avoid any VBUS issues, you can run the test again switching off all other tasks in the DSP just to confirm if it is not a VBUS congestion kind of issue.

    was there any partial corruption of symbol data (0 ~ 13)?

    Regards,

    Albert 

  • 0 in reply to Albert Bae
    Intellectual 300 points

    Hi Albert, thanks for your reply.
    In my program I used exactly 140 QMSS descriptors for the AIF2 rx FDQ,so I assume the 140 symbols(0..139) received will always corresponding to a certain descriptor, like symbol_0 to desc_0, symbol_77 to desc_77.
    When this error happend , for example, I recv symbol(0..9 - 11..14) and lost symbol 10. At this time I read the PDSP ping/pong buf, the desc_11 is follow desc_9, desc_10 is missing here. Then I pop every desc in the AIF2 rx queue, the desc_10 is at the very end !  It is not missing but recycled by AIF2 I think, whether this shows some connection with your advice 1 ?

    Using one fibre cable connect the SFP for self-loopback or using two fibre cables connect the EVM with our FPGA board , both found this issue. Sometimes it appears very soon, sometimes after some hours.

    The data is right, just missing one symbol I think, and symbol 10 is just an example, it always change.
    Is there any documents to let me know about the "VBUS issues", I am not familiar with it.
    Regards,
    ziyang.

  • 0 in reply to zi yang
    TI__Expert 4740 points

    Hi,

    you said you are using 140 Rx free descriptor. Rx descriptor is not automatically recycled by AIF2 HW. your application should check the received data and push it into the Rx free queue manually. (AIF2 HW only auto recycle Tx descriptors)

    descriptor has no its original index, then how do you know each symbol is matched with each rx descriptor? rx descriptor is just simply re-cycled and re-used by Rx PktDMA machine to transfer incoming Rx symbol data in order.

    you said you lost descriptor 10 at that time but I don't understand what it means. I guess you are saying that you received symbol 9 on descriptor 9, symbol 10 on descriptor 11, symbol 11 on descriptor 12.............., symbol 138 on descriptor 139, symbol 139 on descriptor 10. is it correct? (still I don't know how do you know the descriptor index) 

    about VBUS issues, you can check it from data manual table

    Switch Fabric Connection Matrix Section 1

    In case of Turbo Nyquist (6618), AIF2 shares bridge7 with SRIO, PCIE, EDMA1TC2, RAC for DDR access.

    if you have any application which access DDR3 from SRIO, PCIE and EDMA1TC2, you need to check the traffic if it causes bridge contention when you lost the symbol packet.

    Regards,

    Albert

  • 0 in reply to Albert Bae
    Intellectual 300 points

    Hi,

    Sorry for my poor english that I can not describe it very well.

    I wonder whether there has some similar problems here, but now I think I should check if there any program errors in my code and find more details for my problem.

    Thanks for all your replies here.

    Regards,

    ziyang

  • 0 in reply to Albert Bae
    Intellectual 300 points

    Hi Albert,

    Thanks for your reply.

    I  have spent a lot of time on this issue , and I found that not only one reason can cause this.

    I enabled the EE of AIF2 and try to find something.

    Sometimes I found that the "cd_ee_sop_desc_starve_err"  register is growing when the error happen,  what doos it mean? For Tx or Rx?

    And sometimes I fount that "pe_ee_db_starve_err" register is also related,  is a an urgent error and cause my problem? what showload I do to fix this?

     

    And for my "descriptor index" you mentioned, I use 140 RX desc from a QMSS region,  their point address are 

    continuous, which is  a descriptor len,  I push them into the RX FDQ in this order and they will be poped into the RXQ in order because it is a queue.  Also I recycle them in sequence. So I think that we can use the CCS to see their pointer to calc their index in 140? Am I corrent?

    Regards,

    ziyang. 

     

  • 0 in reply to Albert Bae
    Intellectual 300 points

    Hi,  Albert Bae.

    This AIF2 problem happens again  and I opened a new post  here to discuss,   Sorry to bother you.

    http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/356785.aspx