How to evaluate STM32F7 bus matrix performance and solve bus matrix performance issues?

[arnold_w]

I am working with the STM32F769 microcontroller and very rarely I experience some strange issues with an SPI slave and I suspect it's related to congestion on the bus matrix (other, primarily DMA, transfers ongoing at the same time). Is it possible to somehow "look inside" the bus matrix and evaluate how it is performing? What are some recommended ways to solve congestion on the bus matrix (it's already running at maximum clock speed)?

[STOne-32]

Dear @arnold_w ,

Here is an Application Note AN4667

https://www.st.com/resource/en/application_note/an4667-stm32f7-series-system-architecture-and-performance-stmicroelectronics.pdf  
you can see impact of DMA and some tips to optimize overall performance while selecting right memories for SPI buffers and other masters . Have a good lecture .

Ciao

STOne-32 

[Piranha]

SPI overloading the bus matrix running at 216 MHz? What else is running there?

Judging by other topics, you are using HAL and CubeMX generated code. If that is the case, there is no point in suspecting bus matrix or other highly unlikely issues, while there is the HAL/Cube code, which is broken in countless ways, especially for Cortex-M7.

https://community.st.com/t5/stm32-mcu-products/maintaining-cpu-data-cache-coherence-for-dma-buffers/m-p/95746

https://community.st.com/t5/embedded-software-mcus/bug-missing-compiler-and-cpu-memory-barriers/td-p/298508

 

[arnold_w]

I think it might be because all DMA-buffers were located in DTCM and it seems like a long way (via the core!) for the data to travel between the DMA controllers and DTCM. I've moved the DMA-buffers to RAM and I'm running tests to see if the problem has disappeared.

[Piranha]

As I already said, if you are using HAL and other broken code, all of those guesses and assumptions are useless. For the device to be reliable, the code must be correct. There is no way around it! As for the correctness and testing:

Therefore one can test as much as one wants, but it still doesn't prove anything. Have you fixed the issues reported in these links?

https://community.st.com/t5/embedded-software-mcus/bug-stm32-hal-driver-lock-mechanism-is-not-interrupt-safe/td-p/289837

https://community.st.com/t5/embedded-software-mcus/bug-broken-state-management-in-stm32-hal-drivers/td-p/578044

If no, then what's the point in wasting a time on "testing" a broken code?