Problem with SPI slave, getting 0xAA on first transaction

[tetiana]

I'm using NRF51822 as SPI slave and STM32 as SPI master. Everything works fine except the first SPI transaction after resetting both boards.

On the first transaction I'm receiving 0xAA on STM while SPI slave on NRF falls into waiting for transmitting bytes I need. So, right after I reset STM32 I'm getting data from Nordic (STM initiates transaction on a high external interrupt from Nordic and checks it on the start). And all subsequent transactions go well.

Another way to get rid of this bug is resetting NRF51822 - after 1 or 2 resets the first transaction in question becomes successful (STM checks if the state of external interrupt pin changed and is active and initiates transaction again).

On the first transaction on the NRF buffers are successfully set, and new buffers are assigned in SPI slave interrupt handler. Second interrupt telling us about completion of transmission event (when NRF_SPIS1->EVENTS_END != 0) never shows up (until the second try from STM32).

Could you please help me with any ideas why this synchronization(?) issue happens on the first transaction only and only after BOTH board were restarted? It looks like it can have a hardware root cause...

[Stefan Birnir Sverrisson]

Hi Tetiana
Can you create the fake transaction by letting the STM32 toggle the CSN line before sending the actual data? The 0xAA character is the DEF_CHARACTER and is usually clocked out when the semaphore is not available to the SPIS peripheral and is occupied by the CPU. I immediately do not see any difference between the failing signals and the successful signals. Are you using the SPI slave example from the SDK unmodified? Are you using softdevice by any chance? Have you tried the communicaton with other SPI master than STM32? Please include information on what version of the chip you are using (the chip markings) and the nRF51 SDK version