[resolved]Can't get SPI clock to stop properly (RXONLY)

Alex Yang · ‎2012-08-07

Posted on August 07, 2012 at 20:21

Hi all, I'm having problem stopping the SPI clock in RXONLY mode.

PB3(SCK) and PB4(MISO) on my STM32F103VBT6 are used to read from a bunch of external shift registers. On-chip resources are allocated as follows:

SPI1:

Master mode with NSS managed by software and never enters slave mode;

two-line RX-only transfers. I/O pins are remapped to PB3 and PB4. (Using SWD and parallel JTAG has been disabled);

Word length: 8-bits;

RXDMA enabled, allowing DMA to manage RXNE events;

No interrupts enabled for SPI module.

DMA1:

Channel 2 enabled, Direction = SPI1 DR register 8bits -> Memory 8bits;

Number of bytes to transfer = 22;

TCIF2 interrupt enabled;

I wouldn't hesitate to paste my code here if it'd help immediately, but to keep the story short, at the moment I'd just like to describe the steps I've taken:

1. Initialize SPI module without enabling SPI1;

2. Initialize DMA module and enable DMA1-CH2;

3. Enable SPI to start transfer;

4. DMA1-CH2 interrupt has been triggered, but SPI1 wouldn't stop sending out SCK unless I add a line specifically to disable SPI1 within the ISR for DMA1-CH2;

5. Read SPI1 DR and clear all related flags. (Even though it might not be neccessary)

Then things start to get more weird: with the added disabling of SPI1, the first transfer would seem right with exactly 22 bytes or at most 23 bytes transfered. But the second time, my oscilloscope shows something like 44 bytes being transfered before DMA1-CH2 interrupt is triggered. I know this because I've made a GPIO flip itself as soon as the program enters DMA1CH2 ISR. When this happens, OVR is set to 1. What could have prevented DMA from generating a TCIF flag right after 22 bytes have been received?

I've read RM0008 Rev.11, consulting

Fig. 244,

Section - 24.3.8 Disabling the SPI,

Section 24.3.9 - SPI communication using DMA.

The manual only highlights precautions for disabling SPI during receive-only transfers. Precise timing is required to prevent corruption of the last transfer, or sending more garbage SCK signals after the last useful clock cycle.

But the manual didn't say whether SCK would stop itself in DMA mode after all bytes have been transferred. I had decided to try and I found that it doesn't stop. Are my findings wrong?

How should I configure these modules to minimize software intervention? I need some clues, thanks.

#stm32-spi-rxonly

Alex Yang · ‎2012-08-10

Posted on August 10, 2012 at 19:36

Ok, here's what I've learned after getting some help from a friend.

A) When working as master in RXONLY mode, SPI clock DOES NOT stop until the SPI module is disabled, even if DMA is enabled to help with reception.

B) Given the circumstances described in A, the only possible cause of excessive SPI clocks is DMA TC interrupt had been delayed, and as a result, SPI module couldn't be disabled in time.

I checked my code and found USB interrupts had been assigned higher priority than DMA TC interrupt which was serving SPI RX transfer. I swapped priority and kept DMA ISR as short as possible, now the SPI transfer looks neat, without compromising other activities.

Personally I think it is silly not being able to stop SPI clock automatically with the aid of DMA. I mean dude, there's a counter which specifies number of words to be transfered, who would ever need extra clocks with nothing reading the data after all the transfer is done?

I'm trying to minimize the steps required to re-arm the SPI and DMA. Hopefully disabing modules, restoring some registers, clearing some flags and re-enabling modules would suffice.