Query related to capture using McBSP2 using SDMA

Girisha

The first thing to do is re-confirm that the the McBSP receiver configuration does match that of the transmitter.  If you give me you McBSP configuration (register dump) and part number of the transmitter device (and any configuration settings if any)  I'll see If I can help varify the setup.  

Since the transmited data will be random it will be hard to validate the data in the file agains the source. To do this you could connect the receiver to a McBSP transmitter and send known values. You should then be able to compare the contents of the original against what was received.  The additional transmitted could be another McBSP or the the transmitter of the same McBSP looped back.

  Paul

Following is the configuration for McBSP2 device

rcr2_reg      = 0x00000001
rcr1_reg      = 0x000003A0
xcr2_reg      = 0x00000001
xcr1_reg      = 0x000003A0
srgr2_reg      =  0x000010FF
srgr1_reg      =  0x00001F00
mcr2_reg      = 0x00000201
mcr1_reg      = 0x00000201
rcera_reg      =  0x0000000F
rcerb_reg      =  0x00000000
xcera_reg      =  0x0000000F
xcerb_reg      =  0x00000000
pcr_reg         = 0x00000F03
sysconfig_reg     =  0x00000000
thrsh2_reg      =  0x00000000
thrsh1_reg      =  0x00000000
irqenable_reg     =  0x00000000
xccr_reg      =  0x00001008
rccr_reg      =  0x00000808

With this configuration tramission(Tx) is fine but receive(Rx) is noisy. What are the possible issues & how can I debug the problem ?

If you have any implementation that does the receive operation can you please share with me ?

Girisha

What device are you connecting too? If it's configurable, what's the configuration?

  Paul

My setup is like McBSP2 is connected to CS42448 Codec chip and application transfers the data to McBSP2 using SDMA transfers.

I have shared the McBSP2 configuration & below is the SDMA configuration for capture,

ccr   |= ((1<<5) | (1<<18));
ccr   |= ((0) | (1<<14));
ccr   |= (1<<24); 
ccr   = ((33 + 1) & 0x1f) | (((33 + 1) & 0x60) << 14);
csdp  =  (1<<1);   
cen   =  256;                           
cfn   =  ((10*1024*1024)/(256 * 4));
csr   =  (0x1ffe);
cicr  =  (1<<3);
csf   =  1;
cssa  =  0x49022000;  //McBSP2 address
cdsa  =  AppBuffPhysicalAddr;

We are not very much concerned with the codec configuration as it is already being tested for capture using drivers that come with QNX & driver written on DSP BIOS.

Sorry order of ccr initialization needs to be reversed and is as below,

ccr   = ((33 + 1) & 0x1f) | (((33 + 1) & 0x60) << 14);
ccr   |= ((1<<5) | (1<<18));
ccr   |= ((0) | (1<<14));
ccr   |= (1<<24); 
csdp  =  (1<<1);   
cen   =  256;                           
cfn   =  ((10*1024*1024)/(256 * 4));
csr   =  (0x1ffe);
cicr  =  (1<<3);
csf   =  1;
cssa  =  0x49022000;  //McBSP2 address
cdsa  =  AppBuffPhysicalAddr;

I am suspecting SDMA parameters when used along with McBSP. I am more keen in understanding the relationship between them.

Using SDMA I would like to transfer 1024 bytes of data from McBSP to application buffer.

Girisha SG said:

We are not very much concerned with the codec configuration as it is already being tested for capture using drivers that come with QNX & driver written on DSP BIOS.

I asked for the codec configuration so that I can compare with the McBSP configuration and verify they match.

  Paul

Girisha

I have assumed the CS42448 Codec is transferring data in TDM mode since you are setting up a single phase frame and all the other codec modes are dual phase frames.

So, in TDM mode the codec will transmit a fixed frame as follows:

  8 slots of 32 bits in a 256bit frame. Active high frame sync is either 1 bit or 1 word.
  each slot contains 16, 18, 20, or 24 bits of data with MSB first.
  Data is output on the falling edge of the clock with 1 bit delay

So the MASTER MCBSP2 configuration for this should be:

rcr2_reg    = 0x1, single phase, MSB first, 1 bit delay.

rcr1_reg    = 0x7A0, 8 words per frame, 32 bits per word.

srgr2_reg   = 0x10FF, same as your configuration. FPER = 256bits
srgr1_reg   = 0x1F00, frame width 32 clock periods. Could also be 0x0 for 1 bit FWID.
mcr1_reg    = 0x0, No multiple devices.
pcr_reg     = 0xA03. FSR and CLKR should be inputs as they are driven by FSX and CLKX. 
              Note that PADCONF for FSX and CLKX should have the input enabled!!
thresh1_reg = 0x7? Determines when a DMA even occurs and how many words to transfer.
              Must match the DMA configuration.  

That’s the basic receiver configuration that I came up with.  However, I could not verify your clock source (SCLKME + CLKSM) or your SRG divider setting (CLKGDV).

I see you are trying to use the multi channel setup. It looks like you are trying to extract the first 4 words from the frame, is this correct? If it is, then you could probably just set the rcr1_reg to 4 words per frame and that should probably work ok.

I’ve not checked your transmitter setup.

  Paul

I am already having a working code on DSP that uses EDMA3 & McBSP for transfer, now I am porting this on ARM where I am replacing EDMA3 with SDMA.

I want to understand for the McBSP settings that I have mentioned above when will the interrupt get generated to connected SDMA device(as I could see McBSP frame size is 128 bits but in DSP code callback registerd to EDMA3 LLD gets invoked after every 1024 bytes). I am little confused about this

Girisha SG said:

ccr   = ((33 + 1) & 0x1f) | (((33 + 1) & 0x60) << 14);

I think you have en error here. The shift operation should be 19 in order to to write the SYNCHRO_CONTROL_UPPER bits.

  Paul

Girisha

A couple of other observations:

Girisha SG said:

cen   =  256;       
cfn   =  ((10*1024*1024)/(256 * 4));

You are setting the frame size (cen) to 256 elements. The block size (cfn) to 10240 frames. Therefore you will be writing 2621440  16bit words to your buffer in frames of 256 words.

You have the source to be  read one element at a time (FS=1, and BS=1) so DMA read will happen for every word received by the McBSP.

So, in addition to the shift error, you should change the cfn value to 1026/cen, 1024/256 = 4. ie, the DMA transfer is now 4 frames of 256 16bit words.

You may also consider changing the source setup so that the MCBSP is read less frequently. Keeping the frame size of 256 you could set FS=1 and BS=0 so that an entire frame is transferred for each McBSP2 DMA request. You would also have to adjust the THRESH1_REG value (0xFF) to match the frame size. This makes better use of the McBSP receiver buffer.

  Paul

Thanks for the input, it was really helpful.

I have one more query, I could see there is a 256x32 bit internal buffer in SDMA,

1. Will it be possible for me to utilize this such that McBSP THRSH1_REG is set to 0x0 i.e. McBSP generates interrupt to SDMA for every word but SDMA interrupts the CPU(i.e. ISR gets called) after 256 words( each word is 32 bits).

If possible then I can keep the existing McBSP configuration same & at the same time when ISR gets called I will be having 1024 bytes of data(i.e. 256 words).

Girisha

Yes, it is possible to use the DMA buffer to build up the write packet from 256 individual element reads. However, the DMA buffer is shared between logic channels and therefore using it in such a manner may cause issues for other DMA events. Here's the text from the TRM:

9.4.2 FIFO Queue Memory Pool

A FIFO queue memory pool provides buffering between the read and write ports. The hardware allocates the space dynamically to a number of FIFO queues, and each queue is associated with an active logical channel.

To avoid a memory pool overflow, if there are fewer entries in the FIFO queue memory pool than are required for the maximum configured source burst size of the next logical channel to be scheduled, the logical channel is returned to the tail of the queue, and the port access scheduler continues to search the queue until it finds a logical channel that can be scheduled.

The maximum FIFO depth that can be allocated to each individual logical channel can be limited globally through the SDMA.DMA4_GCR register. This value should be configured to allow a fair allocation of the memory pool between the active channels.

A logical channel is scheduled if it has not yet reached its allocation limit, even if the access to be performed will exceed this limit. This means that the effective number of entries used by a particular logical channel is limited to the configured maximum entries per channel + channel maximum configured burst size (in words) -1.

  Paul

Thanks.

From the above description I understand that Its better to configure SDMA to generate interrupt to CPU whenever it receives interrupt from McBSP. Am I right ?

Girisha

Yes, it is better to use the DMA interrupt to signal the completion of data written to the memory.

 Paul

My McBSP configuration is as shared earlier, I have gone through the TRM & I have configured SDMA as follows,

csdp           =  2; // 32-bits
cen            =  256; // 256 elements / frame
cfn            =  1024; // Frames / block
csf            =  0x1; // Packet transfer mode with each transferring 32bit
ccr            = ((33 + 1) & 0x1f) | (((33 + 1) & 0x60) << 14); // Hardware synchronized transfer, 14 is fine as it will set 20th bit :)
ccr            |= (DMA4_CCR_SRC_CONSTANT | DMA4_CCR_DST_POST_INCR); // source constant addressing, destination post increment addressing
ccr            |= DMA4_CCR_SEL_SRC_DST_SYNC; /* Transfer is trigger by the Source (HW) */
ccr            |= (DMA4_CCR_FS | DMA4_CCR_BS);  /* Packet transfer Mode */
csr            = DMA4_CSR_MSK;
cicr           = DMA4_CICR_FRAME_IE; // Frame interrupt i.e. after every 256 elements
cssa           = i32SrcAddr;  // McBSP2 address
cdsa           = i32DestAddr; // Physical address of source buffer
clnk_ctrl      = DMA4_CLNK_CTRL_ENABLE_LNK | i32ChanNum;
irqstatus[3]   = 0x00000000; // Using line 4 for interrupts
irqenable[3]   = 0x00000003; // Using line 4 for interrupts, enabled interrupt on channel 0 & 1

For the audio capture I have used McBSP2 & SDMA is configured with the intention that McBSP triggers SDMA tranfer for every 32-bit element & generates interrupt after one frame of tranfer(i.e. 256 words). However I am observing the following issues,

1. I am printing whenever I get an interrupt & observing that number of prints are around 195(ideally I must have got 1024 prints / SDMA channel). i.e. I am feeling I am missing interrupts.
2. Observing noisy output in the captured file.
3. Some times bits for both ping & pong channels are set in irqstatus register & hence difficult to differentiate which channel has generated the interrupt.
4. If I increase the buffer 10 MB I am receiveing the data but during channel switching data is missed & it looks like there is a sudden transition.
4. However if I do Tx with 1 MB buffer & read contiguous data from 2 MB file I could hear proper audio output.

Please let me know what could be the reason & how can I debug & resolve. Its highly critical for me !Thanks for your reply I have somemore queries :) ...

Girisha

How big is i32destAddr? I ask because in the other thread I mentioned that you have the DMA configured for  larger than the buffer size you mentioned at the start of this thread (1024 bytes?). The transfer for your current configuration is CEN*CFN, 256*1024 = 262144 words.

Since you are using packet transfer mode, the value in CFSI should equal the McBSP THRSH1_REG setting +1 (THRESH1_REG should be 0 for your configuration).

Now, with your current setup you should still be getting an interrupt after every frame and therfore 1024 interrupts per block. 

Are you printing the diagnostics during the ISR? If you are, could this not cause you to miss an interrupt? If you do miss an interrupt then this may explain why you see two channels  in the status register and why your print count is low.

You could setup a counter in the FRAME_IE interrupt to track the the number of FRAME_IE interrupts received. Also set a BLOCK_IE interrupt to confirm that  the correct number of FRAME_IE were generated, reset the FRAME_IE counter, and continue.  If the count value is not correct then generate a diagnostic.

  Paul

For testing purpose I have increased the buffer size to 1024 * 1024 bytes(once it starts working I will make it 1024 bytes).

I could see that the Value of CFSI register should be McBSP THRSH1_REG  + 1 (also it hangs if I make it 0)

If I print the CCFN register value after every SDMA ISR I could see as below

ccfn 920 csr 72!
ccfn 914 csr 72!
ccfn 910 csr 72!
ccfn 904 csr 72!
ccfn 897 csr 72!
ccfn 891 csr 72
ccfn 887 csr 72
ccfn 881 csr 72
ccfn 876 csr 72
ccfn 871 csr 72
ccfn 865 csr 72
ccfn 860 csr 72
ccfn 854 csr 72
ccfn 848 csr 72
ccfn 843 csr 72
ccfn 837 csr 72
ccfn 831 csr 72
ccfn 826 csr 72
ccfn 819 csr 72
ccfn 815 csr 72
ccfn 812 csr 72
ccfn 806 csr 72
ccfn 801 csr 72
ccfn 798 csr 72
ccfn 793 csr 72
ccfn 787 csr 72
ccfn 782 csr 72
ccfn 780 csr 72
ccfn 773 csr 72
ccfn 767 csr 72
ccfn 762 csr 72
ccfn 760 csr 72
ccfn 755 csr 72
ccfn 749 csr 72
ccfn 741 csr 72
ccfn 739 csr 72
ccfn 734 csr 72
ccfn 730 csr 72
ccfn 724 csr 72
ccfn 718 csr 72
ccfn 713 csr 72
ccfn 707 csr 72
ccfn 703 csr 72
ccfn 698 csr 72

But if I keep a counter & increment it in ISR it is sequential ...

I am not able to understand the issue ...(Also I am not familiar with writing drivers !)

I have gone through TRM for Omap3530 & did the configurations accordingly ... please let me know if there is anything wrong in SDMA configuration with respect the McBSP configuration that I have shared earlier.

sorry the above replay has CCFN & CCR register values ...

Girisha SG said:

For testing purpose I have increased the buffer size to 1024 * 1024 bytes(once it starts working I will make it 1024 bytes).

I could see that the Value of CFSI register should be McBSP THRSH1_REG  + 1 (also it hangs if I make it 0)

My post above (now edited) it was misleading,  CFSI = THRSH1_REG +1.

Girisha SG said:

If I print the CCFN register value after every SDMA ISR I could see as below

ccfn 920 csr 72!
ccfn 914 csr 72!
ccfn 910 csr 72!
ccfn 904 csr 72!
ccfn 897 csr 72!
ccfn 891 csr 72
ccfn 887 csr 72
ccfn 881 csr 72
ccfn 876 csr 72
ccfn 871 csr 72
ccfn 865 csr 72
ccfn 860 csr 72
ccfn 854 csr 72
ccfn 848 csr 72
ccfn 843 csr 72
ccfn 837 csr 72
ccfn 831 csr 72
ccfn 826 csr 72
ccfn 819 csr 72
ccfn 815 csr 72
ccfn 812 csr 72
ccfn 806 csr 72
ccfn 801 csr 72
ccfn 798 csr 72
ccfn 793 csr 72
ccfn 787 csr 72
ccfn 782 csr 72
ccfn 780 csr 72
ccfn 773 csr 72
ccfn 767 csr 72
ccfn 762 csr 72
ccfn 760 csr 72
ccfn 755 csr 72
ccfn 749 csr 72
ccfn 741 csr 72
ccfn 739 csr 72
ccfn 734 csr 72
ccfn 730 csr 72
ccfn 724 csr 72
ccfn 718 csr 72
ccfn 713 csr 72
ccfn 707 csr 72
ccfn 703 csr 72
ccfn 698 csr 72

But if I keep a counter & increment it in ISR it is sequential ...

I am not able to understand the issue ...(Also I am not familiar with writing drivers !)

As I said in my last post, if you are printing these diagnostics from the ISR then you will probably miss some interrupts. That is why when you use the counter it works but printing will only show some of the interrupts.

Girisha SG said:

I have gone through TRM for Omap3530& did the configurations accordingly ... please let me know if there is anything wrong in SDMA configuration with respect the McBSP configuration that I have shared earlier.

As noted above, the only issue I saw was that your CEN * CFN was too large for the 1024 buffer size.  Can you share your code for the buffer definition?

  Paul

I am just copying the CCFN, CSR register values in ISR and I am not printing it there.

In ISR,

1. I am checking whether it is a Frame interrupt.

2. If 1 is true I am masking the interrupt.

3. Copying CCFN, CSR & CDAC register values in structure variables & returning to the main thread.

In the main thread

1. I am clearing the frame interrupt.

2. I am clearing irqstatus register.

3.

    Case 1: I am unmasking the interrupt

                   Printing the values stored in the variables.

    OR

   Case 2: I am printing values stored in the variables.

                  unmasking the interrupt

In both the case there is a jump in register values.

One more interesting thing that I have observed is that CCFN & CDAC register values are jumping properly(i.e. if CCFN value jumps by 3 then CDAC register value is jumping 3*1024 bytes)

For debugging purpose I have commented the all other parts in the code between receiving the interrupt & unmasking it (except the one that I have shared above) i.e. actual processing part is ommented but still I observe this behaviour !!!

Do you have any clue why it is so ???

I am using QNX 6.5.0.

CCFN & CDAC register values are as shown below,

ccfn 741 Cdac 0x88946cec
ccfn 738 Cdac 0x88947800
ccfn 735 Cdac 0x88948400
ccfn 730 Cdac 0x88949800
ccfn 724 Cdac 0x8894b000
ccfn 717 Cdac 0x8894cc04
ccfn 713 Cdac 0x8894dc00
ccfn 707 Cdac 0x8894f400
ccfn 702 Cdac 0x88950800
ccfn 697 Cdac 0x88951c00
ccfn 690 Cdac 0x88953800
ccfn 685 Cdac 0x88954c00
ccfn 680 Cdac 0x88956004
ccfn 674 Cdac 0x88957800
ccfn 667 Cdac 0x88959400
ccfn 661 Cdac 0x8895ac00
ccfn 656 Cdac 0x8895c000
ccfn 650 Cdac 0x8895d804
ccfn 644 Cdac 0x8895f00c
ccfn 638 Cdac 0x88960800
ccfn 633 Cdac 0x88961c00
ccfn 629 Cdac 0x88962c00
ccfn 623 Cdac 0x88964400
ccfn 620 Cdac 0x88965000
ccfn 615 Cdac 0x88966400
ccfn 610 Cdac 0x88967800
ccfn 607 Cdac 0x88968400
ccfn 601 Cdac 0x88969c00
ccfn 598 Cdac 0x8896a800

Girisha

The print statement is too slow compared with the DMA events and this is why you see skipped, non sequential values.

As suggested before, if you simply cound the FRAME_IE interrupts and verify the correct number were generated at each BLOCK_IE interrupt then you will have proven that you are not missing any frames. Only if the value is not as expected print a diagnostic. This only works once as the printing of the diagnostic will cause a count error in the next block, etc, etc.

If you don't use any print statements does you audio play correctly?

  Paul

How can I enable digital loop back to test whether the captured data is proper & can be played back in real time ?

Audio is getting captured & playable (with 1 MB buffer for each Ping & Pong SDMA channels)...

Now I require each of Ping & pong channel to transfer 32-bit * 256 * 1 (CSDP*CEN*CFN) i.e. Now buffer size is 1KB instead of 1 MB as mentioned above. Now I have the problem of irqstatus register getting set simultaneously (I assume transfer is so fast such that before I could read & reset irqstatus register interrupt is getting generated ....)  for both the channels. Because of this I am not able to decide which channel has actually generated the interrupt 1st (so that I can copy the buffer properly) How can I resolve this issue ?

This issue is really critical for me !

Girisha SG said:

How can I enable digital loop back to test whether the captured data is proper & can be played back in real time ?

Can you elaborate?  The digital loopback is used to connect transmit data to the receiver.

To verify the received data you could use a digital loopback setup to loop a set of known data over the transmitter, looping it back to the receiver and then comparing the received data with the data transmitted.

  Paul

I have the a setup where McBSP Tx & Rx works fine with SDMA individually, but when I do Tx & RX together then I am observing chirpling noise in the captured output. What could be the reason & how can I resolve this issue ?

Does anybody has any update ?

Girisha

If not already monitored, check for underflow/overflow errors on the mcbsp.

  Paul

I have verified for underflow/overflow errors using IRQENABLE & IRQSTATUS McBSP registers & could not see any error for both Tx & RX what else could be the reason ?

Girisha

With no underflow/overflow errors (or any other errors?) then I would suspect data issues (even although separate TX and RX operations work fine).

What is you dataflow model ( -> MCBSP RX -> DMA -> ?? -> DMA -> MCBSP TX ->)?

You could possible verify this by looping back the TXD/RXD signals so that you receive whatever is transmitted. verify whatever is in the receiver memory buffer against the transmit  memory buffer.

Paul M.

For Rx:

AuxIn --> McBSP2 --> SDMA --> Application

I am playing a song in PC & audio out is connected as AuxIn. Application does fwrite of the data received into a file.

For Tx:

Application --> SDMA --> McBSP2 --> Speaker

Application does fread to get audio & sends it to McBSP2 using SDMA.

Girisha

A few more questions...

Are the Mic input and speaker output on the same codec and therefore same McBSP or are they different devices? If different are they connected to 1 6-pin MCBSP or 2 MCBSP modules? 

When you are runnig the transmit only test are you using data already using the Mic --> file path?

  Paul

Hello Paul,

Yes Mic input & speaker output are on the same codec.

For transmit I am using seperate file & not that I have captured using Mic-->file path.

Girisha

Ok, I assume the the chirpling noise is heard on the output data.

To summarize the facts:

  TX only works fine
  RX only works fine
  Single codec for both input and output
  No errors reported by the mcbsp for either TX or RX
  Same data file is used for both TX only and TX/RX tests.
  Only when TX and RX are active do you hear the chirpling.

The only other thing I have as a suggestion is to loop your transmitted data back to the receiver and verify the received data against the file containing the transmit data. The fact that the McBSP is not reporting any underflow errors suggests that there the data is being transmitted correctly. By doing the digital loopback test you'll isolate the issue to either internally or externally. If internal, then you'll need to look at the code that loads the buffer that feeds the McBSP

  Paul

Let me check on this...

  Paul

Do you have any update ?

Audio is noisy throughout, after I get 'transmit buffer underflow' error for the very 1st time. If I kill it & relaunch I dont get any underflow error & audio is not noisy !!!

Girisha

An underflow condition will cause the last valid word transmitted to be repeated until the underflow is resolved. Once resolved the data should not have any errors and any "noise" should have cleared. Any additional underflow errors will result in additional "noise".   After the first underflow do you see a constant underflow condition? Is you error checking causing delays such that it would induce further underflows and hence a continued noise output?

Here are a couple of options for you to start the MCBSP without an underflow.

1)  Program SRGR2_REG:FSGM = 0. This will only generate the FSX when there is data to transmit. This will only work if the the McBSP is transmit master.  You still need to ensure that data is written the the DXR on time to avoid underflow errors within a frame.  You will not see any underflow errors between frames. Instead there will be a pause until the a new FSX is generated by writing data to the DXR. 

2) Release FRST after XRST (last reset to be released). This will enable the DMA engine to preload the transmit buffer before generating FSX. The preload can be checked by monitoring the value in the XBUFFSTAT_REG register.

  Paul

Thanks Paul.

After the first underflow do you see a constant underflow condition? Is you error checking causing delays such that it would induce further underflows and hence a continued noise output?

[Girish] : No, I observe underflow condition only once & I clear the status & afterwards I am not observing the error. But audio continues to be noisy.

1)  Program SRGR2_REG:FSGM = 0. This will only generate the FSX when there is data to transmit. This will only work if the the McBSP is transmit master.  You still need to ensure that data is written the the DXR on time to avoid underflow errors within a frame.  You will not see any underflow errors between frames. Instead there will be a pause until the a new FSX is generated by writing data to the DXR. 

[Girish]: With this modification I am not observing any underflow errors but Tx audio will be noisy sometimes.

2) Release FRST after XRST (last reset to be released). This will enable the DMA engine to preload the transmit buffer before generating FSX. The preload can be checked by monitoring the value in the XBUFFSTAT_REG register.

[Girish]: Already I am doing the same.

Girisha

Since there are no errors to point to a possible problem the next thing is to try the loop back test as suggested ealier.

  Paul

One more query is if I start observing McBSP capture buffer overflow how can I resolve the same ?

Girisha

A receiver overflow simply means that you are reading the data from the McBSP buffer slower than the the McBSP is receiving it.

You need to increase the rate that you read data from the receive buffer.

  Paul