DMA for SPI master

RE: DMA for SPI master

Juha Okkonen — Mon, 20 Jan 2014 13:57:15 GMT

I have been trying to make implementation using two timers and spi slave device to handle data transfer every two milliseconds. One timer generates correct SCK for the SPI slave by toggling output pin. Second timer counts pulses and stops first timer. For some reason I can get correct output only if I run code in debugger by stepping source lines. If I just run without breakpoints nothing happens. And usually when stepping and things seem to work correctly otherwise ( I see correct pulse train on logicanalyzer ) debugging freezes immediately after starting both timers. Any ideas what's going on???

Another question; how are functions wired into pins. Can I connect SPI:s SCK to same I/O-pin that timer is toggling. Or is only one function connected at a time. I have seen comments that behaviour is not specified if two different outputs are connected to same PIN, which would seem to implicate that what I want to do is possible. I also need to connect SPI:s CS to a pin thats configured for output.

RE: DMA for SPI master

Bruce — Fri, 13 Dec 2013 20:17:54 GMT

Hi Audun,

I'm not doing much in the GPIOTE interrupt handler, just toggling the debug pin. See the other thread linked below for code snippet.

I'm using app_gpiote and by looking at its implementation, clearing the EVENTS register is the first few things it does.

void GPIOTE_IRQHandler(void) { uint8_t i; uint32_t pins_state = NRF_GPIO->IN;

// Clear event.
NRF_GPIOTE->EVENTS_PORT = 0;

... ...

I opened another thread for the GPIOTE interrupt issue so I don't hijack this post. devzone.nordicsemi.com/.../radio-activity-causes-gpiote-interrupt-missing

Thanks, Bruce

RE: DMA for SPI master

Audun — Fri, 13 Dec 2013 17:42:56 GMT

No problem. Regarding the missing interrupt, as you say it should be skewed when a lower stack interrupt occurs. How much processing are you doing in the GPIOTE interrupt handler? There is a chance that a lower stack interrupt happens while in the GPIOTE IRQHandler. If you haven't cleared the EVENT register at this time and a new GPIOTE interrupt occurs, that new interrupt will be discarded once the EVENT register is cleared. If you aren't already, try clearing the NRF_GPIOTE->EVENTS_x register as the very first thing you do in the IRQHandler.

RE: DMA for SPI master

Guest — Thu, 12 Dec 2013 23:29:33 GMT

Thanks Audun. I was just doing something similar to what you suggested. I'm toggling a debug GPIO in AD's interrupt GPIOTE interrupt handler. However, from the debug GPIO captured by oscilloscope, I'm missing some interrupts if I turn on advertisement or if I'm in a connection.

One thing puzzles me is the GPIOTE interrupt is not skewed, but some of them are missing completely. I would imagine in this case a lower stack interrupt pushes GPIOTE interrupt, but not making it disappear.

Any thought on that?

Thanks, Bruce

RE: DMA for SPI master

Bastiaan — Thu, 12 Dec 2013 23:29:33 GMT

Any thought on that?

Thanks, Bruce

RE: DMA for SPI master

Audun — Thu, 12 Dec 2013 23:01:47 GMT

Ah, I understand better now. Length of the radio interrupt is determined by: a) How much data you have put in the softdevice TX buffer b) Procedures initiated by the Master (channel map update, encryption, etc.)

The softdevice will always try to send as many packets as possible during a single connection event. If you are sending multiple packets, the radio interrupt could be significantly longer (the Master actually decides how many packets can be sent during a connection interval). So, dont put more than X packets (I'm not sure of the exact number) in the TX buffer at a time. Then wait until you get a BLE_EVT_TX_COMPLETE event until you put in more. Secondly, there are control procedures that can happen at any time. There will typically be channel map updates once in a while, but I'm not sure exactly how long radio interrupt that will cause.

Anyway, I suggest using the radio notifications to trigger a GPIO, and use a logic analyzer or oscilloscope to see how long each interrupt actually takes. You can also have a main loop that toggles a GPIO, and you will see the toggling stopping during interrupts. This will give you a better feel of exactly how long each interrupt is. Note that some control procedures, such as channel map updates, is not something the application is aware of, and you would need a BLE sniffer to see when this is happening.

RE: DMA for SPI master

Bruce — Thu, 12 Dec 2013 22:15:23 GMT

Thanks for your reply, Audun.

But unfortunately our AD runs on its own Crystal Oscillator and for sure it will collide with the radio events. Which also implies that we cannot sync AD to radio notifications.

I'm just wondering if there's a way to guarantee AD GPIOTE interrupt is serviced within 2ms (maybe 4ms or 8ms) with radio turned on?

Thanks, Bruce

RE: DMA for SPI master

Audun — Thu, 12 Dec 2013 21:30:47 GMT

Hi Bruce,

the radio notification functionality is a feature that triggers a software interrupt prior to, or after a radio interrupt (see https://devzone.nordicsemi.com/documentation/nrf51/5.0.0/html/group__t__s110___n_r_f___s_o_c___f_u_n_c_t_i_o_n_s.html#ga15378609daca09588e620b64555fc2e8). So if you need to perform stuff uninterrupted between radio events, or synchronize application tasks with radio activity, this is the best way.

In your case, you could enable the radio notifications to give you an interrupt when the radio interrupt is finished. When the radio event finishes, you can start a repeated timer with your AD interrupt frequency. If the bluetooth connection parameters doesnt crash with your AD frequency, you should be able to get a stable AD read frequency. Note that there will be some drift (depending on your clock source), and you would probably want to add some logic to keep your AD timer synchronized with the radio notifications.

RE: DMA for SPI master

Bruce — Thu, 12 Dec 2013 20:27:14 GMT

Hi Audun,

Could you please elaborate on how to synchronize radio activity with the AD reading to achieve 500Hz reading?

I'm in the same situation as Juha that the AD interupts every 2/4/8 milliseconds. And unfortunately, the AD conversion data has to be read out before the next interrupt comes.

Thanks, Bruce

RE: DMA for SPI master

Audun — Tue, 03 Dec 2013 14:21:00 GMT

You can keep track of the length by using a second timer as a counter, stopping the clock when the counter reaches the 9 byte clock value. Possibly the END event in the SPI slave can be of use, but I suspect this event connects to the CSN line.

"Only one peripheral can be assigned to drive a particular GPIO pin at a time, failing to do so may result in unpredictable behavior." You could give it a try, but it's not designed to work like that.. :(

Alternatively it's possible to synchronize radio activity with your AD reads. Have you seen the radio notification functionality? You can use this to synch radio activity with a 2 ms application timer. Depending on the connection parameters and your application behaviour, you might be able to keep a steady 500 Hz AD reading. http://devzone.nordicsemi.com/documentation/nrf51/5.0.0/html/group__t__s110___n_r_f___s_o_c___f_u_n_c_t_i_o_n_s.html#ga15378609daca09588e620b64555fc2e8

RE: DMA for SPI master

Guest — Tue, 03 Dec 2013 14:08:22 GMT

You understood problem correctly. Luckily I dont' need to send anything when receiving values. All configuration is done beforehand. Complication is, that interrupt from AD is kept active only until reading starts. So I don't get signal telling how long to transfer bytes. Only a starting edge. Every transfer is 9 bytes. So do you think it would be possible to generate both clock and length with a timer for the SPI-slave??

Another complication is that I'm currently using BLE-module and not all the I/O-pins are available. It it were possible to configure SPI-slave and Timer -pins to same physical pins, it would be helpful. Is that at all possible. Theoretically I would expect it to be possible when one is output ant other input, but does HW support it?

RE: DMA for SPI master

Bastiaan — Tue, 03 Dec 2013 14:08:22 GMT

RE: DMA for SPI master

Audun — Tue, 03 Dec 2013 13:43:38 GMT

Hi Juha,

just to clarify: the SPI transfer itself is not corrupted, right? As the SPI Master, if you get interrupted in between byte transfers your next byte transfer is simply delayed. The hardware will always complete a byte transfer, even when the CPU is interrupted.

My understanding of the problem is that the data you want to read becomes invalid if you delay reading it for too long.

Unfortunately, there is no DMA support for the SPI Master. Only for the SPI Slave. But it might be possible to use the SPI Slave functionality in this case.

I suppose your AD is a SPI Slave device, and cannot act as a Master. What you would need to do is set up the SPI Slave peripheral. As both SPI devices are now slaves, you need to generate a clock signal on a different pin and connect it to the SPI Clock line. The clock can be generated using PPI and a TIMER. Load up the TX buffer with the required data (register addresses etc., depending on your AD). Configure the GPIOTE to generate an event on the AD interrupt (on both set and release edge), and connect it to your clock timer START and STOP tasks. You might also have to connect the interrupt event to the AD Slave select line. When the AD asserts the interrupt line, your GPIOTE interrupt event will fire, initiating the transfer. With large enough TX/RX buffers, you should be able to line up multiple transfers.

I realize this explanation is a bit messy, but hopefully you can make sense of it.

Audun