Use PPI for auto writing sampled data to flash device?

[Sensorion]

My setup is as follows

• 1 Gyroscope + Accelerometer
• 1 RTCC
• 1 SPI Flash device

I want to set up the PPI to periodically sample the MEMS devices and the RTCC, and then automatically write the data to the SPI flash without involving the CPU.

First off, is this possible?

Secondly, should I use a separate SPI Bus(SPI0) for the Flash and one for the MEMS(SPI1) and one for the RTCC(SPI2)?

Or can I have them all on the same SPI bus and utilize the Slave select lines?

And how do you manage the target write address, as each set of data would have to be written to a high memory address with each subsequent write?

[MartinBL]

Hi

The first issue I see with this is that the Chip Select (CS) pin is not included in the SPI hardware module and needs to be handled in software. This is simply because a hardware module can't possibly know which CS pin to use if you have multiple SPI slaves on the bus. However, you have three SPI slave devices and the nRF52 has three SPIM hardware modules. So if you are willing to sacrifice enough GPIO pins to control three SPI buses you can have one slave on each bus.Then you can simply tie the CS pin on each slave to ground (I believe it is active low) and you won't need to use CPU to select slaves.

Moving on you can use a timer and a forked PPI channel to do the the reading from your MPU and RTCC.

• Use the TIMERx->EVENTS_COMPARE event in a timer to trigger an event.
• Fork the PPI channel and use SPIMx->TASKS_START task to start a simultaneous read operation from the two slaves.
• Use EasyDMA on both read operations and we are still not using any CPU.

Now, when both read operations are completed you can use the SPIMx->EVENTS_ENDRX event to trigger a write operation to your flash on the third SPI bus. One important thing here is that the MPU and RTCC read buffers need to be located next to each other in the nRF52's memory. Otherwise you would need the CPU to "manually" change the buffers to read from. With the buffers located consecutively in memory you can read them out as one long buffer instead.

So, yes, I think it should be doable.

I don't know how your flash device works, but if it has some sort of auto address increment feature I guess it would place each set of data consecutively in its memory by itself.

[RK]

One comment. There are SPI devices which don't function properly unless each transaction starts with a chip select transition. Also, CS usually acts as a state-machine reset in the SPI device which protects you from the case you get a single glitch on the clock line, if that happens, your bit stream is 1 bit wrong until the CS line is strobed and since SPI has no error correction, that can be somewhat important.

So you may get away with tying CS low, but it's something which would bother me.

[MartinBL]

Good point. Maybe one could use additional PPI channels to toggle the CS pins before and/or after a transmission. It is starting to get quite complex though.

[Sensorion]

I am using the nRF52, and I believe that the SPIM drivers include a .SS field in the structure for a slave select line. If I have only 1 device per SPI bus, will this not toggle the relevant SS line? I would think this should take care of RK's point.

But, the whole idea seems to hang on the SPI Flash device having an auto increment feature, correct?

[MartinBL]

Where do you see a .ss field? Neither nRF51 nor nRF52 have dedicated SS pins in hardware. So I guess the idea hangs on the auto increment and (maybe) the handling of the SS.