2014-02-20 09:00 AM
I am using a STM32F4 as a SPI slave. The STM32F4 receives a packet of data over a USART line and must have the data immediately available for use in the SPI communication. I am using a DMA Tx memory to peripheral transfer on the SPI line to quickly shift out data. In order to make the fresh data immediately available to the SPI DMA I am attempting to flush the DMA FIFO buffer to remove the data that was automatically loaded into the buffer after the previous SPI transfer. I reset the EN bit of the DMA register to start the FIFO flush and a little bit later the DMA TCIF bit is set which I think is suppose to signify the flush is complete. However after enabling the DMA again, in the next SPI transfer, the data is incorrect. The first byte sent is the last byte from the previous SPI transfer, the second byte is the first byte of the new data packet, and the third byte is the second byte of the new data packet and so on. I am thinking I am simply not flushing the FIFO buffer and re-enabling the DMA stream properly. I have checked the remaining data counter, DMA_SxNDTR and it shows full number of bytes after a flush. I am not sending too big of a data packet (only 96 bits) but I am stuck in the structure of needing to act as a SPI slave and receive fresh data in real time. Any tips or suggestions would be greatly appreciated.
#stm32f4 #dma_fifo2014-02-20 09:39 AM
2014-02-21 10:07 AM
I have been using a Discovery board to develop my code and I've been testing with the another STM32 Discovery board acting as the SPI Master. I can try to have it write to another SPI on the same chip but that would seem to be very similar to what I'm doing now. If there any other checks I can do besides seeing the TCIF is set after I start a FIFO flush?
2015-06-16 02:39 AM
(I have also replied in the other thread but put this here for anyone looking in the future)
Hi there I have been running an STM32F207 with:and also had the problem where the first word (I am using
16 bit transfers
) was corrupted, or simply not there. I believe I may have found the solution. The problem is that nothing seems to trigger the FIRST load from the DMA into the SPI DR, and it is not until after the first 16 bits have been clocked out that the DMA controller does the first transfer into the DR of the SPI Channel. So it behaves more like as in ''Figure 262: Reception using DMA'' in the STM32F207 Reference Manual. I got around this by :