Problem with SPI slave, getting 0xAA on first transaction

RE: Problem with SPI slave, getting 0xAA on first transaction

tetiana — Mon, 29 Sep 2014 14:44:24 GMT

Have you tried the communicaton with other SPI master than STM32?

No, I haven't and I'm afraid this is hardly possible in the nearby future...

Please include information on what version of the chip you are using (the chip markings) and the nRF51 SDK version

SDK version 6.0.0.43681 Chip QFAAGO

RE: Problem with SPI slave, getting 0xAA on first transaction

tetiana — Mon, 29 Sep 2014 14:29:03 GMT

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

RE: Problem with SPI slave, getting 0xAA on first transaction

Stefan Birnir Sverrisson — Mon, 29 Sep 2014 13:28:27 GMT

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

RE: Problem with SPI slave, getting 0xAA on first transaction

tetiana — Sat, 27 Sep 2014 13:05:01 GMT

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.

RE: Problem with SPI slave, getting 0xAA on first transaction

tetiana — Fri, 26 Sep 2014 14:17:12 GMT

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

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.

RE: Problem with SPI slave, getting 0xAA on first transaction

Asbjørn — Fri, 26 Sep 2014 13:11:02 GMT

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?