Need help with SPORT anomaly on ADSP21992

Hi,

We are facing problem while transmitting data byte by byte using TX interrupt of SPORT ADSP21992.

We have used External clock for SPORT of frequency 5KHz, coming from other processor.

The configuration of SPORT transmit Registers is as follow:

1) SP_TCR = 0x A6E1

    i.e We have configured word length = 8bits, Internal TFS  - active high .late framing and data dependent TFS.

As soon as we enable TSPEN bit in SP_TCR , we get TX interrupt which is desired. We fill data in SP_TX Register in TX ISR and wait for next interrupt to fill next data.

The problem here is that the interrupt is triggered only for the first time and hence interrpt based transmit does not work. We observed that if we add delay around 2.5mSec, interrupt comes for every byte transfer and transmit works fine.

We studied 2199x anomaly where same problem is mentioned in Anomaly6- 6. SPORT generates TFS (Transmit Frame Sync) one clock cycle earlier than expected when configured for data-dependent and early frame sync mode.

(Refer to attached 2199x anomaly document.)

But as per the document this problem is not applicable if

A] The frame sync is configured to be data independent.

OR

B] The frame sync is configured to be late frame sync.

OR

C] DMA mode of data transfer is used.

The condition B is satisfied in our case, but still we are facing the same problem. Our code works ok with workaround (2b) mentioned in the document.

Please help us to find out the correct reason for this problem.

Thanks in advance for your time.

porter

P.S. We see the same problem when we configure the DMA too. We are yet to try the said workaround with DMA option.

ADSP-2199x_anomaly_Rev.B.pdf
  • 0
    •  Analog Employees 
    on Oct 3, 2012 9:26 AM

    Hi Porter,

    Could you please provide more details about your system in terms of what is connected to the SPORT of the DSP ? A simple block diagram with important timing details (SPORT speed, FS speed etc) would be helpful as well?

    Could you please also post the simplest code with which you see this problem as well ?  If possible could you please also post the oscilloscope screenshot of the SPORT related signals (CLK, FS, Data) for both failing and passing case ?

    I would be able to comment  better once I have this information.

    Thanks,

    Mitesh

  • Hi Mitesh,

    Thanks for your reply.

    Please refer attached schematic for SPORT hardware configuration.

    We are using EXTERNAL clock of 5 KHZ for SPORT which is provided by PIC processor.

    I have attached two sample codes files,

    SPORT _working.dsp – This test code works ok ,as we have added delay in TX ISR.

    SPORT _not_working.dsp – This test code does not work, First time interrupt is generated as TX buffer is empty Then the first data i.e 0x3F is filled in TX Register. We get interrupt one more time when 0x3F is moved to shifter register.Now we fill second data 0x42 in TX register and then we never get the interrupt..

    I couldnt get the oscilloscope snapshot of related signals.Let me  know if you think they are absolutely necessary even after information attached here.

    Thanks again

    Porter

  • 0
    •  Analog Employees 
    on Oct 5, 2012 9:19 AM

    Hi Porter,

    Thanks for posting the code. I have following suggestions to debug the issue further:

    1) Just to check if the problem has anything to do with using external TCLK  vs internal clock, could you please check if  you see the problem even when using the internal TCLK ?

    2) Could you please also reduce the delay as much as possible and check what is the minimum delay required to avoid the problem ? If the delay required is only few clock cycles, you might as well add "nop" instructions instead of using a hardware loop. This will help us to check if the issue is related to the effect latency of write to any of the SPORT register.

    3) To simplify the debugging procedure, I would also suggest you to remove the receive part of the SPORT code completely and have a very simple code which just sends out the data on SPORT with in an interrupt based mode with exactly the same configuration which is used in the original failing code. Your main code can be just a plain loop waiting for the SPORT interrupt. Please let me know if you see the problem even with the simplest code. This may help us to know if the problem is related to the other part of the code as well.

    Hope this helps.

    Thanks,

    Mitesh

  • Hi Mitesh,

    Please read my feedback point wise.

    1) As I had mentioned in my first post, our code works if delay is introduced. So the problem couldnt be in source of clock.

    2) The min we tried is 2.5mS (We didnt try any value lower than this, may be it works for further low values) and transmission works with that.

    3) We have already tried removing Rx code and we still see the same problem.

    From the point 2, it is almost clear that issue we are facing is the same as captured in the anomaly sheet i.e. you can not fill the TXreg immediately after transmission begins. This I have already written in my first post but what I wanted to ask is that whyare we facing this issue despite using the configuration of SPORT which is exempted for this anomaly. Please refer my first post for details.

    Let me know if you need anymore information.

    Porter.

    Thanks and regards,

    Abhishek Jain.

  • 0
    •  Analog Employees 
    on Oct 5, 2012 10:40 AM

    Hi Abhishek,

    Thanks for the details. Please see my comments below:

    porter wrote:

    Hi Mitesh,

    Please read my feedback point wise.

    1) As I had mentioned in my first post, our code works if delay is introduced. So the problem couldnt be in source of clock.

    Mitesh>> Sorry for not being clear in my previous post. The reason why I asked you to try with internal clock is because the SPORT's behavior may change when using internal vs external clock. to be able to comment on the root cause, we may have to narrow down the problem to smaller set of conditions and I think it may be worth trying this test.

    2) The min we tried is 2.5mS (We didnt try any value lower than this, may be it works for further low values) and transmission works with that.

    Mitesh>> Again, let me be more clear on why I asked to perform this test. Sometimes, there are some effect latencies are associate for the write to a core/IOP registers. Because of the  fact that the code works for a particular delay in your case, I think its worth finding out the minimum possible amount of delay required to be able to avoid the problem.

    3) We have already tried removing Rx code and we still see the same problem.

    Mitesh>> Thanks. In that case, could you please post the simplest code (without RX and without communication to the PIC etc) which still shows the problem? That will help us to simplify the debugging procedure.

    From the point 2, it is almost clear that issue we are facing is the same as captured in the anomaly sheet i.e. you can not fill the TXreg immediately after transmission begins. This I have already written in my first post but what I wanted to ask is that whyare we facing this issue despite using the configuration of SPORT which is exempted for this anomaly. Please refer my first post for details.

    Mitesh>> As you can see the anomaly is not applicable for late frame sync mode. Moreover, the anomaly should cause problems only when the TFS signal and should not affect the interrupt. Thus, before concluding this to be a new anomaly, I think, we should try to narrow  down the problem by removing various irrelevant code and conditions and make sure that the problem is not because of using a wrong programming model. Thus, I would request you to please get back to the above mentioned tests so that we can debug this issue further.

    Let me know if you need anymore information.

    Porter.

    Thanks and regards,

    Abhishek Jain.