I am working with an ADSP-21363 SHARC DSP where I use SPORT channels to receive and transmit left-justified audio stream.
SPORT1 (RX) handles the reception of N audio samples (left-justified) through DMA.
SPORT0 (TX) handles the transmission of N audio smaples (left-justified) through another DMA channel.
Both SPORT modules are configured in left justified mode with external frame-sync and samples clocks. The DMA channels are confgure to work in chain mode (double bufferd/ping-pong) DMA.
I have a very specific question regarding the start up of my SPORT/DMA channels. Obviously I can not start the DMA transaction on both SPORT modules synchronously as I need to write into 2 different registers one after another. Normally (as far as I understand) the SPORT/DMA transfer will start on the next rising frame sync edge. Now imagine the following sequence:
(external clock and frame sync running)
T+0 = Enable/start SPORT RX transfer by writing into the configuration register.
T+1 = Rising frame sync edge activates the RX channel (LEFT first).
T+2 = Enable/start SPORT TX transfer by writing into (another) configuration register.
T+3 = The TX channel will wait for the next rising frame sync edge before starting the transmission (LEFT first).
Question: Is it somehow possible that the TX transfer will start on a falling frame sync edge (RIGHT first)? I don't think so but I really need to be sure as I see a LEFT/RIGHT swap on the TX channel from time to time and I am trying to figure out if it's the hardware on rather my processing and copy routines that create the mess.
Bit 16 of the SPCTLx register (L_FIRST) can be toggled to choose whether you want to frame the data starting from rising/falling edge. For more details, please refer the Hardware Reference manual.
I have spent some time debugging my problem now so let me ask you another question.
1. Let's assume I configure a SPORT as transmitter.
2. I enable it without having written to the TX buffer.
3. When the frame sync edge arrives the SPORT will report a buffer "underrun".
Even without having loaded anything into the TX word buffer will the SPORT still copy the empty TX word into the shift register and start shifting it out? If this is the case it would explain my issue.
As per the HRM: " As a transmitter, if FSR = 1, the DERR_x bits indicate whether the SPORTx_FS signal (from an internal or external source) occurred while the DXS buffer was empty."
Yes, I think the SPORT will transmit the previous word in case of an under-run. Having said that, I think, it may not be of much importance whether the SPORT sends zero or the previous word in case of an under-run as that data is any way invalid. I am just curious to know if this is of any significance for your application.
the significance for my application is that there is a bug in the firmware which cases the audio data transmitted on SPORT (TX) to be channel inverted (L/R). This problem doesn't happen every time but rather sporadically. My responsibility is to clearly identify the root cause of the bug and to make sure that it never happens again. In our application a problem like this can cause significant damage.
I think that by now the error is identified and all I need is a confirmation of my theory. The SPORT channel was obviously configured and enabled in the wrong order.
1. Configure the SPORT channel.
2. Enable SPORT by setting the SPEN bit.
3. Enable DMA by setting the DMEN bit.
Steps 2 and 3 were separate writes to the configuration register. In addition there was some extra code between steps 2 and 3 which introduced a considerable delay.
What happened is that sometimes after step 2 a rising edge of the frame sync signal was detected and the SPORT started shifting out one (empty) word from the shift register. At this moment the shift register is blocked. We then enable the DMA channel which will write the first sample (left) into the SPORT tx register. As the shift register is busy the SPORT tx register cannot be copied imediately into the shift register but rather on the next frame sync edge. This causes the first true sample (left) to be finally shifted out on a falling frame sync edge and not as expected on the first rising edge.
All I needed to do was to set the DMAEN bit before enabling SPORT with the SPEN bit and it works fine.
Thanks for the details. You are correct that the SDEN_A/B bit should be either enabled in the same instruction which enables the SPORT (SPEN_A) or earlier. I understand that after following the correct sequence, the issue is solved.
Please do let me know in case you have further questions.