RE: NRF52 SPI CS Not working after wakeup

Marco — Sun, 26 Feb 2017 23:52:44 GMT

We found the bug. We were using GPIO pin 12 for both a SPI and a TWI interface. The same initialisation procedure was performed both before and after System OFF. The only difference was in the order in which the interfaces were initialised: before System OFF the SPI was initialised first, after System OFF the TWI was first. By swapping the initialisation order, we set what interface is actually controlling (having priority over) the GPIO pins.

RE: NRF52 SPI CS Not working after wakeup

Chris — Sat, 25 Feb 2017 04:51:26 GMT

Hi Ole, we will produce this when we get back to the office. I had thought the same thing when I went home :-)

It won't take long to whip up the code so you can run it on the DK and we can confirm that we're also seeing it without too much else in the way. Otherwise we'll start cutting out code/re-introducing until the error show's it self.

RE: NRF52 SPI CS Not working after wakeup

Ole Bauck — Fri, 24 Feb 2017 16:49:25 GMT

Do you have a stripped down version of the code that will reproduce the problem on a nrf52 DK (PCA10040)?

RE: NRF52 SPI CS Not working after wakeup

Marco — Fri, 24 Feb 2017 10:28:30 GMT

I add some details in support to Chris. We had to run some tests on PCA10040 because it is easier to debug. When we try to read (command 11) the PARTID (register 2) or any other register from the ADXL263 on our device, we always get value 0x0.

I am providing here few screenshots of some tests run on PCA10040 (without SX9300). Channel 0 to 3 are the SPI lines (Clock, SDI, SDO, Enable).

In this first case everything works fine. Then we go into System OFF. Once we come back to System ON (triggering a GPIO pin) we perform the same SPI initialisation and try to read the same register. And this is what happens:

SPI is Enabled way before the actual read. Once the read is performed SPI Enable is deasserted. Those 2 spikes (Clock and SDI) correspond to the zoomed signals in the first picture.

For additional testing we have then modified file "nrf_drv_spi.c". Every time GPIO pin "p_cb->ss_pin" is set/clear we do set/clear the output GPIO pin 20. And this is what we get (before and after System OFF):

Before moving into System OFF pin 20 tracks properly SPI Enable signal.

And this is what happens after System OFF.

UPDATE

We have been running few tests. We made a stripped down version of our code simply performing a SPI read and going into System OFF waiting for an interrupt on a GPIO line. And it works. Then we tried our original code by just changing the GPIO pin assigned to SPI Enable signal (from GPIO 12 to GPIO 17) and it works as well (tested on PCA10040, no sensor actually connected to selected SPI GPIO lines): SPI Enable is going low allowing SPI transactions after coming out of System OFF (see following 2 screenshots).

Channel 7 (GPIO 20) is still tracking SPI Enable (GPIO 17). And we still get the initial weird behaviour (GPIO 20 does not follow SPI Enable rising edge). But then we can actually complete the following SPI Read operation.

And this is the zoomed view of the SPI transaction.

In our code GPIO 12 is only used for SPI Enable signal. And in case of mistaken multiple usage of it, I would expect an error to be reported back. But all APP_ERROR_CHECK() are successful. We will now proceed analysing our code in order to track down where and what the error is. Do you have any information about known bugs that might cause such wrong behaviour? It looks like something else is driving GPIO 12. While GPIO 17 is fine.