SPORT0 I2S interrupt

Spetca,

Have you ever solved this? I have the same problem, and I notice similar problems from several others on this forum.

Thanks,

-Erik

In my post I say:

BufferRx[RXcnt] = *pSPORT0_TX16;

this is merely a typo should be

BufferRx[RXcnt] = *pSPORT0_RX16;

Still not sure why it behaves like it does. I can get it to behave properly closely counting the frame syncs after RSPEN, but intuitively it does not work in various configurations of using:

something = *pSPORT0_RX16

*pSPORT0_TX16 = something

Hi Shane and Erik,

You need to write to Sport TX fifo in Sport TX ISR and read from Sport RX fifo in Sport RX ISR. You are currently performing everything in SPORT TX isr(like SPI).

Below link to the thread has several Sport codes in Core and DMA mode. Please refer them,

https://ez.analog.com/thread/70566

Thanks,

Sachin

Sachin,

Thanks for your reply. The issue is memory. We both are using the original talkthrough sample code to minimize code size. One stereo sample at a time.

I have it running with the adi_xxx functions right now, but am really fighting all the memory space that they take up. Stepping into that code, I see that buffering the DMA calls with large buffers solves it, but code that has worked for over 10 years on a 533 should work on a 592. Sounds like a bug in the silicon to me.

-Erik

Hi Eric,

If you are able to solve the issue by just increasing the Sport buffer size, this likely can't be a silicon bug. It looks like you are having some buffer synchronization issues in your code. If you are performing some processing on the receive buffer, you must make sure that this processing is done within the capture of next buffer. BF533 and BF592 are different Speed grade parts. So BF592 may take more time to process when compared to BF533.

Thanks,

Sachin

While I hate to contradict, I completely emptied out the ISR, and it still only hit at 4Hz. And what buffer sync? I have two samples, one for each channel. ISR after the pair.

And 400MHz vs. 500MHz is not that great of a difference when we are talking 32kHz.

Hi Erik,

I believe by adi_xxx functions, you mean device drivers and system services(DDSS) . So your implementation is based on DDSS .Hence your old code must be based on examples provided in VDSP.

Are you referring to these,

VisualDSP 5.1\Blackfin\Examples\ADSP-BF533 EZ-KIT Lite\Audio Codec Talkthrough - I2S (C)

This example provided here doesn't use ping-pong buffering mechanism which is good for real time processing. Instead it just enables DMA's in Auto buffer mode. This may be acceptable for codes like talk through or simple processing schemes because it assumes that all the processing will be done within the (1/32)ms( At this rate core clock frequency and complexity of processing algorithm really matters).

Instead of this, you can simply go for two buffer or ping pong buffer mechanism. In this case, while One buffer is being filled, other buffer can be processed in real time. You can achieve this by configuring DMA's in descriptor mode with two descriptors pointing to each other.With this you will get lot more head room for buffer processing ie.. Buffer size *(1/32) ms.

In the earlier case (1/32)ms , there will be a loss of buffer synchronization when you take more than (1/32)ms to process buffer. In the Auto buffered DMA when buffer processing takes more than (1/32)ms there will be some data belonging to last buffer and some with the current. This is what I mean by loss of buffer sync. With this you will surely hear noise.

With newer DDSS implementation are you facing any issues?

Thanks,

Sachin

This question has been assumed as answered either offline via email or with a multi-part answer. This question has now been closed out. If you have an inquiry related to this topic please post a new question in the applicable product forum.

Thank you,
EZ Admin