Foreword
For a few days, a customer feedback, when using the STM32H7 FMC, if D-Cache is running abnormal. The data is not written to the outside of the FMC, and the FMC interface has no waveform. It is normal without making D-Cache. It is normal.
In fact, for this problem, if you understand the architecture of STM32H7, it is easy to understand. Let's take a look at the reason why it is made to make the customer feel that the FMC is not working properly after DCache.
STM32H7 architecture
Below is a part of the STM32H7 architecture diagram and the FMC. As can be seen from the figure, STM32H7 is based on a Cortex-M7 kernel, with a 16KB D-Cache and a 16KB I-Cache in the Cortex-M7 kernel. The kernel connects to the 64-bit AXI bus matrix through the AXIM bus, and then connects to the external memory to the FMC interface through this bus matrix. Here, when the D-Cache is enabled, the operation of the memory on the FMC interface can be used to the kernel's cache.
The benefit of Cache is to improve the speed of the kernel access memory. Why can the cache improve the speed? Because the kernel is not performed directly to manipulate these memories each time, the kernel is not read directly from the cache, or the data is written to the cache. Seeing this, is it a bit linked to the phenomenon mentioned in front of customers.
Cache operation
There are two ways to simply say that the cache is working: back and written.
Back and write [Write Back] is the data usually only to the cache [cache], if necessary, synchronize to the next memory.
Lookup [Write Through] is that the data is written to the cache and the next memory each time. This approach can solve the problem of inconsistency, but it will also consume more bus access time.
The cache is moderated, there is a default setting after enabling the cache. That is, the following table:
Please refer to AN4839 to learn more about the instructions on Cache.
Problem analysis and solving
The customer is an additional FPGA through the NOR storage controller of the FMC. The mapped address range is 0x60000000 ~ 0x7FFFFFF. As can be seen from the above figure, it default cache mode is WBWA (write write write allocation). That is, after the DCache is turned on, all operations for this address range will come to the cache. This also explains why the customer discovery data is not truly written in an external memory. The customer's data needs to be written in the FPGA in real time. So the settings for the application, the settings of the reply are not suitable.
For this app, you can configure it through the MPU, set the Cache of the 0x60000000 ~ 0x7FFFFFFFFFFFFfff, so that the data will be written in the FPGA in real time. Therefore, in this case, we can solve it by MPU reasonable configuration.
Access access and Cache policies can be configured by MPU. The corresponding functions and routines in the HAL library are provided. The reference routine can solve the customer's problem with the following code. Data is written directly to the FPGA each time, not the DCache to the kernel.
Summarize
The use of D-Cache can help us improve the performance of the program, but it will bring the time uncertainty of the cache and the second-level memory data inconsistent and the buffer not strike, requiring customers to apply according to the actual application. Choose. For data that is high in real-time requirements, you can use the MPU to configure into a written mode, or put the data into the DTCM RAM. In addition, a partial storage area of the FMC map is configured in this article. In actual use, the properties of all used storage (such as flash, SRAM zones) should be reasonably configured according to the actual situation, so as not to cause other problems. For details, please refer to An4838. Read the full article, original text title: Case that the FMC peripheral is not working in a case of D-Cache
Article Source: [Micro Signal: STM32_STM8_MCU, WeChat public number: Texas Instrument] Welcome to add attention! Please indicate the source of the article.
Our other product:
