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

[hmolesworth]

edit: piqued++; // why do I bother ..

You may be having this issue:

"3.29 [198] SPIM: SPIM3 transmit data might be corrupted
This anomaly applies to IC Rev. Rev 2, build codes QIAA-Dx0, KAA-Dx0. It was inherited from the previous IC revision Engineering D nRF52840.
Symptoms Transmit data from SPIM3 is corrupted.
Conditions: Data accessed by CPU location in the same RAM block as where the SPIM3 TXD.PTR is pointing, and CPU does a read or write operation at the same clock cycle as the SPIM3 EasyDMA is fetching data.

Consequences Transmit data from SPIM3 is corrupted.
Workaround Reserve dedicated RAM blocks for the SPIM3 transmit buffer, not overlapping with application data used by the CPU. In addition, synchronize so that the CPU is not writing data to the transmit buffer while SPIM is transmitting data."

Changing code or moving RAM can have the unexpected side effect that the SPIM memory moves. There are some posts on this, worth a search perhaps but best to dedicate a RAM block just to SPI3. Hard to predict when a failure will occur, unless all other cpu RAM access are blocked.

NRFX_SPIM3_NRF52840_ANOMALY_198_WORKAROUND_ENABLED is worth looking at; don't know if that helps (I haven't studied it).

This spim3-sending-wrong-data-byte link might help