cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H7 Flash RCC Problem

ketlen
Associate II

Hi,

When I was using the STM32H743ZI chip, I set the system frequency of the chip to 160 MHz. Only enable the ICache, do not enable the DCache and the MPU.According to the prompt from CubeMX, the maximum peripheral clock is 240 MHz. Therefore, I configured HPRE as 1, as shown in the following figure:

ketlen_0-1754647199964.png

During the test, I found that if I disabled the ICache, LWIP was unable to obtain the IP address.If I configure HPRE as 2, LWIP can successfully obtain the IP.Using Wireshark to capture the data on the network, no DHCP protocol was found. That is to say, the Ethernet data was not sent out. However, during the debugging process, the Ethernet data was sent out through the sending function.

Using a logic analyzer to test the data of the MDIO bus under the two configurations, I found that the MDIO versions automatically parsed by the logic analyzer were different. However, the values of all the registers of the PHY were the same in both cases, except for the status register. The test results of the logic analyzer are as shown in the following figure:

ketlen_1-1754647618262.png

ketlen_2-1754647635564.png

Additionally, when the system clock frequency is 160 MHz, even after adding some code, LWIP may still fail to obtain the IP address. However, when the system clock frequency is 320 MHz, after adding the same code, LWIP can successfully obtain the IP address. When the system clock is 160 MHz, if the value of Flash Latency is modified to FLASH_LATENCY_2, LWIP can successfully obtain the IP address, as shown in the following figure:

ketlen_3-1754648396445.png

When the Flash Latency is set to FLASH_LATENCY_2, the system clock frequency is increased from 160 MHz to 320 MHz, and LWIP operates normally.

Based on the test results, after using the ICache, there were issues with the instructions read from the Flash, but not all the Flash devices had problems. If the ICache was turned off, all functions were normal.

3 REPLIES 3

Is there a question in there somewhere?

The FLASH latency needs to be adequate for the ART and prefetch to work properly. Likely to Hard Fault if wrong. VCAP and voltages can impact reliability too.

Disabling caching of internal flash shouldn't be necessary, and suggests other latent issues.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Saket_Om
ST Employee

Hello @ketlen 

Please refer to the table "FLASH recommended number of wait states and programming delay" in the reference manual to set the good flash latency.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.
Saket_Om

ketlen_0-1754993275110.png

According to the table provided in the reference manual, if the AXI peripheral clock frequency is 80 MHz, the voltage range is VOS0, and the Flash latency at this time should be 1WS. When the code is generated by STM32CubeMX, the Flash latency is FLASH_LATENCY_1, which is consistent with the manual. However, during the actual test, it was found that the Ethernet still could not operate normally. Only when I modified the Flash latency to FLASH_LATENCY_2 or FLASH_LATENCY_3, could the Ethernet operate normally.

ketlen_1-1754993708421.png

ketlen_3-1754993955159.png

The current version of STM32CubeMX being used for this project is 6.8.0, and the version of the HAL library being employed is 1.9.1.