This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem with SPI slave, getting 0xAA on first transaction

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

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

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

Children
No Data
Related