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...

[Asbjørn]

I would check the state of the GPIOs used for the SPI interface after the reset. It sounds like they might have different startup time and hence could respond unpredictably initially until you've gained control over both of them. Especially since this only occurs if you reset both of them at the same time. How long after the reset before you start sending/using the SPI interface? Do you still see the same behavior if you wait longer and are sure that both sides are initialized and are ready?

[tetiana]

Asbjørn, thanks for your comment. Pins look to be in the same states. Here are screen-shots from the failing transaction, from the most general view to closer:

link text

link text

link text

and the next successful one:

link text

Time between resets doesn't matter. And restart is not so important here - I can make second transaction run successfully without restarts just by adding some fake transaction before needed one.

[tetiana]

The key details on the lower level are: for the first transaction second interrupt in the SPI state SPI_BUFFER_RESOURCE_CONFIGURED and EVENTS_END being set never comes up. I can see the first interrupt with SPI state SPI_BUFFER_RESOURCE_REQUESTED which arrives when I set the buffers but the second interrupt appears only with the second try from SPI master.

[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

[tetiana]

Hi, Stefan!

Can you create the fake transaction by letting the STM32 toggle the CSN line before sending the actual data?

Yes, that's how I've fixed it for now, though it really doesn't seem like a real fix, and I still wonder about the root cause

Are you using the SPI slave example from the SDK unmodified?

There are some modifications, the SPI slave example is integrated into something bigger, but the main logic is the same.

Are you using softdevice by any chance?

Yes, I'm using SoftDevice 110. To make SPIS working with SD I've changed SPIS's priority from low to high (APP_IRQ_PRIORITY_HIGH). Otherwise interrupts never came at all. SPIS initialization with NVIC_ is made prior to SD init (though I tried initing SPI the other way, after sd init and via sd calls, too).