Post Go back to editing

[SC589] Data from EPPI not written to memory by DMA

Hi, I have Sharc Audio Module (SC-589) kit and I am interfacing it with the EVAL-7768FMCZ (eval board for the AD7768 ADC). The ADC has been left to its default/reset SPI configuration, hence it has the following parameters:

  • DCLK: 4 MHZ
  • Fmod: 1 MHz
  • Decimation rate : x1024
  • Hence DRDY: ~977 Hz
  • Each channel is output via its own DOUTx pin.

Currently I'm only concerned with Channel 0 -->DOUT0.

EPPI of the SC-589 has been configured in GP mode with external clock and frame sync 1.

  • EPPI0 FS1 <-> 7768'S DRDY
  • EPPI0 CLK <-> 7768'S DCLK
  • EPPI0 D00 <--> 7768's DOUT0

EPPI has been configured to have DLEN: 8 bits out of which the LSB corresponds to DOUT0's data. I have enabled MSB and LSB swapping for the incoming bytes in tandem with packing of 4 bytes for 1 32-bit packet for the DMA transaction.

Configuration of EPPI0's registers:

  • EPPI0_CTL = 0x0C0205C
  • EPPI0_LINE = 4096u
  • EPPI0_HCNT = 32u
  • EPPI0_HDLY = 0u

There are 4096 DCLK cycles between each successive incoming FS pulse from the ADC (due to the decimation rate) but the useful header and ADC data is output in the first 32 clock cyles per channel, hence the aforementioned configuration of the LINE and HCNT registers.

EPPI0's DMA (DMA channel 28) is configured in auto-buffer mode. The code snippet below lists the configuration: (Note: I am using the ARM Cortex A-5 to configure the DMA and EPPi0)

								ENUM_DMA_CFG_AUTO | ENUM_DMA_CFG_XCNT_INT | ENUM_DMA_CFG_ADDR1D;							// Configuration Register

*pREG_DMA28_XCNT	=	8u;		// Each DMA transaction consists of 4 bytes. 8*4 --> 32 packed bytes will
//                  correspond to complete 8 channel acquisition of 1 sample from ADC
*pREG_DMA28_XMOD	=	0x0004;		// Since PSIZE and MSIZE = 4 bytes
*pREG_DMA28_ADDRSTART=	sample_dump;				

sample_dump has been declared earlier as an array of unsigned 32 bit integers with size 8.

uint32_t sample_dump[8]

DMA is also configured to raise an interrupt whenever XCNT number of transactions are completed (8 MSIZE transactions).

adi_int_InstallHandler(INTR_EPPI0_CH0_DMA, EPPI0_Interrupt_Handler, 0, true);

Interrupt Handler:

void EPPI0_Interrupt_Handler (uint32_t iid, void* handlerArg)
	gpio_result = adi_gpio_Toggle(ADI_GPIO_PORT_B, ADI_GPIO_PIN_12);
	*pREG_DMA28_STAT = ENUM_DMA_STAT_IRQDONE;			 //Clear the W1C interrupt status bit

A GPIO pin is toggled whenever the interrupt is raised. It is observed in tandem with the DCLK and DRDY signals on a logic analyer.

The DMA and EPPI0 are then enabled.

*pREG_DMA28_CFG	   |=	0x0001;


When debugging the code, I can check that the framing sync signal and the clock are working correctly and the interrupt is raised. Observation of the logic analyzer reveals that the GPIO pin is toggled ~32 DCLK cycles after the DRDY falling edge.

But no data is ever written to the array sample_dump.

What could the reason be for the DMA NOT writing to the memory region denoted by sample_dump?


Update 1:

Looking at the DMA28_ADDRSTART register during debugging, I can observe that the sample_dump was placed at address 0xC1407D50 by the linker.  From the Core0.ld script, it is obvious that it lies in thge MEM_L3 region. I assume the failure of the DMA to populate sample_dump might be due to cache related issues, hence placing it in MEM_L2_UNCACHED would be a possible solution.

However, using either of the following does not result in the pacement of the buffer in the desired region/address space:

uint32_t sample_dump[ARR_LENGTH]__attribute__ ((at(0x20084000))) ={0xFFFFFFFF,0,0xFFFFFFFF,0,

uint32_t sample_dump[ARR_LENGTH]__attribute__ ((at("__l2_uncached_start"))) ={0xFFFFFFFF,0,0xFFFFFFFF,0,

#pragma section("__l2_uncached_start")
uint32_t sample_dump[ARR_LENGTH]={0xFFFFFFFF,0,0xFFFFFFFF,0,

sample_dump is still pointed at the memory space starting from  0xC1407D50. Can someone provide the correct syntax or steps?

Update 2: (11th August 2021)

So I came across the ADI convenience function for disabling the L1 and/or L2 caches. Samples fetched from the EPPI are now written by the DMA channel to the sample_dump buffer.

But I would still appreciate an answer to the query listed under Update 1.

Added details about a possible reason for failure of DMA to populate buffer.
[edited by: alborg at 2:05 PM (GMT -4) on 9 Aug 2021] Addition of link and explanation which solved my problem. My query is still unanswered though.
[edited by: alborg at 7:01 AM (GMT -4) on 11 Aug 2021]
[edited by: alborg at 7:02 AM (GMT -4) on 11 Aug 2021]