SPI failure in case of modifications to unrelared code segment

[Jawad]

Hi everyone,

I am using nrf52832 with SDK version 11.0 for an IoT application. I am communicating with Atmel ATWINC 1500 module through SPI in order to connect to Wifi. My code was working fine until I added few new lines of code unrelated to SPI. Now when I run the project on Nordic hardware I get following SPI read errors.

(APP)(ERR)[spi_data_read][385][nmi spi]: Failed data response read...(00) (APP)(ERR)[spi_read_reg][625][nmi spi]: Failed data read...

I know that this error occurs when there is some issue with pin assignment for SPI interface but I have verified all the pin assignments. The stranger thing is that the project starts working fine if I comment out any part of the project totally unrelated with SPI. Following are the results when I compile the project using Eclipse.

'C:/Program Files (x86)/GNU Tools ARM Embedded/5.4 2016q3/bin/arm-none-eabi-size' _build/nrf52832_xxaa.out text data bss dec hex filename 56312 1436 37904 95652 175a4 _build/nrf52832_xxaa.out

It might be a memory issue or some other issue. I have tried debugging it but failed so any leads or suggestion about where the problem might be or how to debug such an issue will be highly appreciated. My Make file and start up file is attached.

arm_startup_nrf52.s Makefile

[t_prachar]

Was there ever resolution on this issue?  I see a similar issue where SPIM transfers result in invalid data intermittently. Increasing stack size made no difference, but taking out about 18KB from BSS eliminates the error.  The project (gcc) isn't overly large,and RAM usage is modest.  On 2KB SPIM reads, the typical failure is the entire buffer is read back as 0x00.  I can repeat the read operation and it usually succeeds on the second attempt.

This is with SDK15.0 and all error codes are being checked and no return errors are noted.  nrfx_spim driver on SPI instance 3 on the nRF52840.  gcc version 7.3.0.

Start of .ld file (we have SD140 and the USB bootloader also loaded)

MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
RAM (rwx) : ORIGIN = 0x20007000, LENGTH = 0x39000
}

Failure case:

   text    data     bss     dec     hex filename
 300308    1860   46588  348756   55254 _build/nrf52840_xxaa_V3.out

Success case:

   text    data     bss     dec     hex filename
 289332    1860   28784  319976   4e1e8 _build/nrf52840_xxaa_V3.out

[bjorn-spockeli]

t_pracharIs NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED when you see the issue?

[t_prachar]

Enabling that workaround fixes the problem.  Thanks!

We did not consider this workaround required because the the transmit and receive buffers are not touched by the CPU when the SPI transfer is in progress.  Perhaps the ambiguity is in what is meant by "same RAM block" in the errata description.  Perhaps you can describe in more detail what is meant by this phrase in this context since it is apparently a block that is larger than the buffer used by the SPI peripheral.  Does the "RAM block" mean "RAM section" as laid out in section 4.2.1 of the nRF52840 datasheet?  Or "RAM AHB slave"?

[bjorn-spockeli]

t_prachar: Great! The CPU does not have to touch the buffers the bug may occur when the CPU is writing or reading to the same RAM block as where the SPI3 DMA buffers at the same time as the SPIM is fetching data from RAM. 

t_prachar said:

Does the "RAM block" mean "RAM section" as laid out in section 4.2.1 of the nRF52840 datasheet?  Or "RAM AHB slave"?

 By different RAM Block we mean different RAM AHB Slave.

Best regards

Bjørn