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?
