SPIM with DMA Problem?

[HelmetWithHornInstalledInside]

Hi, when debugging, I'm encountering this problem where relevant SPI registers (likely status registers) signaled a successful read before the actual data could be pulled into the memory.

Elaborating it a bit further: when using library function nrf_drv_spi_transfer, the function will return with a success code, albeit the data not having been updated into the designated memory area.

If I set a breakpoint somewhere before the function call, chances are everything will work normally, and it feels almost as if the memory update lagged a good several clock cycles behind.

This is my speculation and I cannot fully confirm this, but with previous experiences regard DMA and external interface, this is actually quite frequent occurrence.

uint32 dwt_read32bitoffsetreg(int regFileID,int regOffset)
{
    uint32  regval = DWT_ERROR ;
    int     j ;
    uint8   buffer[4] = {0} ;
		
RDA:    int result = dwt_readfromdevice(regFileID,regOffset,4,buffer); // Read 4 bytes (32-bits) register into buffer 
		
		if(result == DWT_SUCCESS)
    {
			regval = *((uint32_t*)buffer);
		  if((regval==0x00)||		(regval==0xFFFFFFFF))
        goto RDA;
			else 
				return regval ;
	  }
   goto RDA;

    

} 

Note that this is such a problem I had to add in goto directives to "fend off" all 1 and all 0 reads (0xFFFFFFFF or 0x00000000).

So my questions are:

1. Is this caused by DMA or improper configuration of the SPI interface, or something else?

2. Is it possible to disable DMA and get everything to be processed by the core?

[haakonsh]

Well, the most common method for data transfers in drivers for DMA peripherals is a non-blocking transfer function and a event handler that notifies the application when a transfer is completed. How do you handle the SPIM events?

[HelmetWithHornInstalledInside]

I built everything based on the SPIM example from the Nordic SDK (version 17? or so) downloaded from NordSemi official site.

That said, I pull data from SPI using on of the example function with a pointer pointing to the receiving buffer as parameter passed in.

I didn't care much for callbacks/handlers. Is it possible that you can only successfully update rx data with a handler? That would be a rather strange design.

[haakonsh]

I suggest you share the relevant code, then I can see what's going on. If you're not using an event handler and the transfer function is non-blocking, then you will most likely get the kind of issue that you're observing.

[HelmetWithHornInstalledInside]

Hello Haakonsh, I have found the problem.

I believe the status (most likely) register would trigger SPI's library read+write function to return the result once data is detected on the SPI bus, even though the data hasn't been updated to the designated buffer area.

This is particularly noticeable when the transmission speed is 125K.

I put a 2ms (yes, that much) delay in the function and it fixed the problem.

So basically, after that library function returned, I wait for 2ms for the data to "actually" be updated to the buffer in the memory.

Cheers.

[haakonsh]

Hey Helmet, 

That API call is most likely non-blocking and that ~2ms delay is the time it takes to transfer your data. If you used the API as intended then you can use that ~2ms for something useful.

BR,
Håko  Holdhus