Problems with SAM3U and SSC Rx DMA

laforge · **Joined:** Sun Feb 26, 2012 8:46 pm **Posts:** 1

After weeks of debugging, I'm are finally quite convinced that I'm doing everything in order to use the sam3u SSC DMA as specified, but still cannot get the SSC receive path to work with the DMA/DMAC.

I have plenty of experience in programming sam7s controllers and have previously written code that successfully does SSC+PDC on those smaller controllers. However, sam3u introduces the HDMA/DMAC, and now I experience unexplained total failure for SSC Rx DMA.

The problem seems to be in the andshaking between the SSC peripheral and the HDMA/DMAC controller. Despite the SSC happily receiving data and putting it in RHR, the correctly configured DMA transfer never gets initiated.

Did anyone hear something about an Errata on the SAM3U regarding the SSC Rx + DMA functionality?

My conclusions are based on:

* The SSC Receive path is configured correctly, as SSC_RXRDY is repeatedly set and SSC_RHR contains valid input data when read via software

* The DMA transfer gets started immediately when we switch from HDMA_FC_PER2MEM to HDMA_FC_MEM2MEM, i.e. memory to memory transfers. Of course, due to the lack of flow control, the same RHR value is then DMAed over the entire destination buffer.

* I have attemted to make it working using both my own code as well as
by modifying the at91lib SSC Tx DMA sample to Rx function. The behavior is identical in both cases: The DMA is never started, and SSC_RHR overflows as the DMA is not picking up incoming data.

I can DMA successfully from other peripherals to memory, and from memory to memory. But the DMA never gets triggered on SSC receive.

Does anyone have sample code or experience with SSC in receive mode with DMA?

Thanks in advance

IBE · **Joined:** Fri Dec 23, 2011 2:38 pm **Posts:** 10

Sorry that I can't help yet, maybe in a few weeks.
Cause then I also have to get data from I2S to RAM via DMA.

przemekbary · **Joined:** Fri Mar 09, 2012 1:34 pm **Posts:** 68

Hi!
Is the problem solved? Could you attach the code?

przemekbary · **Joined:** Fri Mar 09, 2012 1:34 pm **Posts:** 68

Did you try to use software handshaking and then forcing the transfer through DMAC_CREQ register? I haven't tried that personally, but that's what came into my mind. Maybe that is some foothold.

__grzegorz__ · **Joined:** Tue Jun 19, 2012 1:43 pm **Posts:** 1

Been fighting with the very same issue as laforge, and I've found solution:

in HDMA_CFG, instead of 3 for SRC_PER use 4.
All details are given in manual (paragraph 7.6)

in board.h find

Code:

/// SSC DMA hardware handshaking ID
#define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_3

and change it into

Code:

/// SSC DMA hardware handshaking ID
#define BOARD_SSC_DMA_HW_SRC_REQ_ID      AT91C_HDMA_SRC_PER_4

Sample code:

Code:

//własna procedura odczytywania danych z SSC (dane word, pojedyncza transakcja o zadanej długosci)
void SSCReadBuffer_DMA(void *buffer, unsigned int length)
    {
    //odczyt całych słów z SSC
    struct _AT91S_HDMA_CH *DMA_PTR = &AT91C_BASE_HDMA->HDMA_CH[BOARD_SSC_DMA_CHANNEL];

//    ASSERT(length<0x1000,"DMA transfer too long...");

    // Clear any pending interrupts
    DMA_GetStatus();
    //adresy...
    DMA_PTR->HDMA_SADDR = (unsigned int)(&AT91C_BASE_SSC0->SSC_RHR);
    DMA_PTR->HDMA_DADDR = (unsigned int)(buffer);

    DMA_PTR->HDMA_CTRLA = AT91C_HDMA_SRC_WIDTH_WORD | AT91C_HDMA_DST_WIDTH_WORD | length;
    DMA_PTR->HDMA_CTRLB = AT91C_HDMA_DST_ADDRESS_MODE_INCR | AT91C_HDMA_SRC_ADDRESS_MODE_FIXED |\
       AT91C_HDMA_FC_PER2MEM |\
       AT91C_HDMA_SRC_DSCR_FETCH_DISABLE | AT91C_HDMA_DST_DSCR_FETCH_DISABLE;
    DMA_PTR->HDMA_CFG = AT91C_HDMA_FIFOCFG_ENOUGHSPACE | AT91C_HDMA_SOD_DISABLE |\
       AT91C_HDMA_DST_H2SEL_SW | AT91C_HDMA_SRC_H2SEL_HW | \
       BOARD_SSC_DMA_HW_SRC_REQ_ID | BOARD_SSC_DMA_HW_DEST_REQ_ID;
    }

Works like a charm

Regards from Poland.

nathaniel29607 · **Joined:** Sun Mar 31, 2013 12:10 am **Posts:** 1

Laforge, your statement

"Despite the SSC happily receiving data and putting it in RHR, the correctly configured DMA transfer never gets initiated."

would be music to my own ears right now. Could you post your SSC receiver configuration code for receiver clk_options and frame options?

I have everything working/playing on my project except a '0' in RHR rather than valid data consistently. I wish the sam3u-ek had come with a recording setup example.

Past experience is mostly with PIC32 processors, but almost up to speed with SAM3.
Nate

przemekbary · **Joined:** Fri Mar 09, 2012 1:34 pm **Posts:** 68

Good job Grzegorz. Persistance always pays off.

Pozdrowienia

Makk · **Joined:** Sun May 12, 2013 12:44 pm **Posts:** 2

Hi,
I am trying to interface my sam3u with TLV320AIC3254 codec in DSP mode using the SSC0 peripheral without dma.
I am able to play some DTMF tones from an array that I created manually and its working fine except that there is some voice before the tones actually starts to play.
When I try to make loopback by reading from the ADC and sending the same read data to DAC, I dont get any voice. I am getting some data in the read register of the SSCo but the voice is not there.
Kindly give any suggestions to solve this problem.
My MCLK = 12.28Mhz....BITclk = 256Khz and WCLK = 8KHz.
My TCMR= AT91C_SSC_CKS_DIV |AT91C_SSC_CKO_CONTINOUS|AT91C_SSC_CKI|AT91C_SSC_START_FALL_RF|((((BITS_BY_SLOT*SLOT_BY_FRAME)/2)-1) <<24)

TFMR == (BITS_BY_SLOT-1) | AT91C_SSC_MSBF | (((SLOT_BY_FRAME-1)<<8) & AT91C_SSC_DATNB) | AT91C_SSC_FSOS_POSITIVE
|( 1<< 16)

RCMR = AT91C_SSC_CKS_TK | AT91C_SSC_CKO_CONTINOUS |
((1<<16) & AT91C_SSC_STTDLY) | (0x1 <<

| AT91C_SSC_CKI

RCFR = AT91C_SSC_MSBF | (BITS_BY_SLOT-1)

Please let me know how I can use the DMA for TX and Rx

Problems with SAM3U and SSC Rx DMA

Who is online