dmammolo opened a new issue, #11594: URL: https://github.com/apache/nuttx/issues/11594
I am observing issues on the SPI interface using IMUs (BMI055 and ICM40688-P) on a pix32v6 (STM32H7 with both IMUs on SPI1). All IMUs use the `spi_exchange()` function to send a command and read back the FIFO data of the IMU. https://github.com/apache/nuttx/blob/55ec92e181165e3f34c12c7a3e719709c38409bd/arch/arm/src/stm32h7/stm32_spi.c#L2047 The issue I am observing is corrupted RX data, basically the data that is received is not the one that is expected. After some debugging and reading I suspect that the dcache invalidation of the rx dma buffer is done too early, i.e. before the SPI transfer and read even started. Currently the invalidation is done here: https://github.com/apache/nuttx/blob/55ec92e181165e3f34c12c7a3e719709c38409bd/arch/arm/src/stm32h7/stm32_spi.c#L2170-L2174 But IMO it should happen here: https://github.com/apache/nuttx/blob/55ec92e181165e3f34c12c7a3e719709c38409bd/arch/arm/src/stm32h7/stm32_spi.c#L2253-L2257 Before we copy the dma buffer on the local buffer(orig_buffer). Debugging with gdb I observed that the copying is successful (verified with memcmp) but when comparing the content of the dma buffer `priv->rxbuf` (I assume by printing the content of the buffer(using it's address) using gdb it does not use Dcache) with the `orig_buffer` it sometimes differs. The issue is hard to reproduce and probably just an edge case. I.e. By changing a random line in my code the issue can start popping up or disappears again. Thus fixing this issue is not so easy. After some investigation I found this document from STM ([AN4839](https://www.st.com/resource/en/application_note/dm00272913-level-1-cache-on-stm32f7-series-and-stm32h7-series-stmicroelectronics.pdf)), from which I extract that we have to do following: - Dcache clean before TX transmit - Dcache invalidate before reading the DMA updated memory region, i.e. the dma buffer. And this has to happen **after** the SPI transmission/reading! Here some citations from the document making that clear: ``` 4 Mistakes to avoid and tips ... if the software is using cacheable memory regions for the DMA source/or destination buffers. The software must trigger a cache clean before starting a DMA operation to ensure that all the data are committed to the subsystem memory. After the DMA transfer complete, when reading the data from the peripheral, the software must perform a cache invalidate before reading the DMA updated memory region. ``` ``` Another case is when the DMA is writing to the SRAM1 and the CPU is going to read data from the SRAM1. To ensure the data coherency between the cache and the SRAM1, the software must perform a cache invalidate before reading the updated data from the SRAM1. ``` Note, that the STM32F7 implementation follows above suggestions. the STM32H7 implementation did that too until this PR changed that logic: https://github.com/apache/nuttx/pull/1040 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
