Thank you for your answer.
The reason why I require to send SPI data in multiples of 32 bytes is, the driver we use. The driver
SPI_Transfer() is provieded by Keil uVision. And if SPI data is not a multiple of 32 bytes the driver uses
HAL_SPI_TransmitReceive_IT() instead of
SPI_Transfer() is not my own implementation.
About the main takeaway points:
The cache maintenance logic needs to clean/invalidate 32-byte aligned addresses.
The SPI buffers (
spi_drv_sMisoFrame ) used in
ABCC_SYS_SpiSendReceive() should be 32-byte aligned.
In abcc_spi_drv.c I added the alignment for the MISO and MOSI frame.
__align(32) static drv_SpiMisoFrameType spi_drv_sMisoFrame;
__align(32) static drv_SpiMosiFrameType spi_drv_sMosiFrame;
section(".DMA_SRAM1") defines the region in SRAM1. The mapping files shows the following:
.DMA_SRAM1 0x30000240 Section 1152 abcc_spi_drv.o(.DMA_SRAM1)
spi_drv_sMisoFrame 0x30000240 Data 576 abcc_spi_drv.o(.DMA_SRAM1)
spi_drv_sMosiFrame 0x30000480 Data 576 abcc_spi_drv.o(.DMA_SRAM1)
The DMA controller on the H7 does not use caching and interfaces directly with (non-TCM) RAM (as can be seen in Figure 1 of the application note above).
I use SRAM1 and DM1 Stream 2 and 3.
SPI peripheral data size should be either 8-bit or 16-bit.
hspi2.Init.DataSize = SPI_DATASIZE_8BIT;
Consider adding pad after the SPI buffers’ declarations.
I don’t understand exactly what you mean by this.
Consider using DMA on non-cached memory regions.
The reason for SPI data in multiples of 32 bytes is the CMSIS driver provided by Keil uVision. I will contact Keil and ask if there is another solution here. I have the same problem with the UART driver.
And if I understand it correctly, it should not be a problem if data is still sent after the CRC. Is that correct?
Many thanks for the good support!