cancel
Showing results for 
Search instead for 
Did you mean: 

IRQ from SPI DMA Rx Complete before end (too early)

snigg
Associate III

I use an SPI interface with Rx and Tx DMA to transfer a 22 byte buffer from a spi slave. Chip select is handeled with

LL_GPIO_ResetOutputPin(TDK_nCS_Port, TDK_nCS_Pin);

set to high again to end transfer I wanted to use:

// SPI5 - IMU TDK Rx

void DMA2_Stream3_IRQHandler(void) {

if (LL_DMA_IsActiveFlag_TC3(DMA2)) {

LL_DMA_ClearFlag_TC3(DMA2);

Imu_Icm42688_DMA_RxCompl();

} else if (LL_DMA_IsActiveFlag_TE3(DMA2)) {

LL_DMA_ClearFlag_TE3(DMA2);

Imu_Icm42688_DMA_Error();

}

}

I can accept that using TxComplete is not working as it fires when last byte is written to interface buffer (therefore not yet sent). But why on earth can the RxComplete IRQ fire too early. See image below for..

0693W00000QLg38QAD.jpg

7 REPLIES 7
KnarfB
Principal III

What chip? Using FIFO?

hth

KnarfB

Which STM32?​

> 22x8bit

Did you​ count them?

Do you use simplex or bidir mode?​

snigg
Associate III

Thx for your time.

I use the stm32f767. Both DMA are in heavy use (UART, SPI, SD-Card).

I do not use double buffer if that is meant by FIFO.

Yes I actually counted all the 22x8 clock pulses just to be sure since I really could not make any sense out of it.

I stuck pretty close to the ST example for SPI DMA full duplex out of the current F7-examples.

// RX DMA Stream

LL_DMA_ConfigTransfer(DMA2, LL_DMA_STREAM_3,

LL_DMA_DIRECTION_PERIPH_TO_MEMORY | LL_DMA_PRIORITY_MEDIUM | LL_DMA_DOUBLEBUFFER_MODE_DISABLE | LL_DMA_MODE_NORMAL |

LL_DMA_PERIPH_NOINCREMENT | LL_DMA_MEMORY_INCREMENT |

LL_DMA_PDATAALIGN_BYTE | LL_DMA_MDATAALIGN_BYTE);

LL_DMA_ConfigAddresses(DMA2, LL_DMA_STREAM_3, LL_SPI_DMA_GetRegAddr(SPI5), (uint32_t) imu_icm42688_rx_buffer.raw, LL_DMA_DIRECTION_PERIPH_TO_MEMORY);

LL_DMA_SetDataLength(DMA2, LL_DMA_STREAM_3, 22);

LL_DMA_SetChannelSelection(DMA2, LL_DMA_STREAM_3, LL_DMA_CHANNEL_2);

// TX DMA Stream

LL_DMA_ConfigTransfer(DMA2, LL_DMA_STREAM_4,

LL_DMA_DIRECTION_MEMORY_TO_PERIPH | LL_DMA_PRIORITY_MEDIUM | LL_DMA_DOUBLEBUFFER_MODE_DISABLE | LL_DMA_MODE_NORMAL |

LL_DMA_PERIPH_NOINCREMENT | LL_DMA_MEMORY_INCREMENT |

LL_DMA_PDATAALIGN_BYTE | LL_DMA_MDATAALIGN_BYTE);

LL_DMA_ConfigAddresses(DMA2, LL_DMA_STREAM_4, (uint32_t) imu_icm42688_tx_buffer.raw, LL_SPI_DMA_GetRegAddr(SPI5), LL_DMA_DIRECTION_MEMORY_TO_PERIPH);

LL_DMA_SetDataLength(DMA2, LL_DMA_STREAM_4, 22);

LL_DMA_SetChannelSelection(DMA2, LL_DMA_STREAM_4, LL_DMA_CHANNEL_2);

MBoom.2
Associate

I have the same issue on STM32G0. Did you find a solution yet?

gbm
Lead III

(Deleted wrong answer) The problem might be related to the famous FRXTH bit setting.

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice

Please don't hijack threads. Start your own thread, possibly giving link to this one; stating what's your hardware, software, what did you do, what are the expectations and how are observations different from them.

[EDIT] But yes, I am curious too, whether the original problem in this thread was solved.

JW

In my case it was "data" in the double registered SPI buffer. I had to ensure Rx-Buffer is completely empty either by dummy data read or read the state (count) of current data.