STM32H743 Using Ethernet Without Cache Issue

[ahmetufukgok]

GOAL

To use Ethernet + LwIP on the STM32H743 chip without cache.

Explanation

We don't want to use the cache when using Ethernet because when the cache is enabled and data is sent and received via DMA on the SPI line, the correct data doesn't propagate to the bus due to a cache miss. Disabling the cache resolves this issue, which is why we prefer not to use the cache when using Ethernet.

Cube Versions:

STMCubeIDE v1.18.1 

STMCubeMX v6.14.1

STMCubeFW_H7 v1.12.0

We used the settings in the following link to configure the project by @Adam BERLINGER 's project: https://community.st.com/t5/stm32-mcus/how-to-create-a-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308.

The CubeMX configurations are as follows:

CORTEX_M7 configurations

ETH configurations

LWIP configurations

Problems Encountered When Cache is Disabled

1. Usage Fault: The device enters a Usage Fault error when the program execution branches into the function SCB_InvalidateDCache_by_Addr() within the following call stack:

ethernetif_input() > low_level_input() > HAL_ETH_ReadData() > HAL_ETH_RXLinkCallback()

2. Bus Fault: A Bus Fault error occurs during a memory copy operation from the IP header address within the following call stack:

MX_LWIP_Init() > ethernet_input() > ip4_input() > ip_addr_copy_from_ip4()

Workaround

The issues are not observed when SCB_DisableDCache() is called immediately after HAL_Init(), even though the Data Cache is already disabled in the CubeMX configuration.

However, the problem persists under specific conditions:

• Errors are still encountered when debugging is entered for the first time without the device's power being cycled.

• The problem does not appear when the device's power is cut and debugging is entered immediately afterward.

• The error is not observed when debugging is entered after the device has been powered on and off a few times.

(This behavior was tested by defining counters saved in EEPROM within the respective fault handling functions.)

I would be happy if you have an idea about this topic. Thanks in advance.

[mƎALLEm]

Hello @ahmetufukgok and welcome to the community,

Try to comment out the calls related to the cache functions when you disable the cache.

For example uncomment  the call of SCB_InvalidateDCache_by_Addr()

[ahmetufukgok]

Shouldn't the solution you mentioned already happen automatically after the MX generation? Under normal circumstances, shouldn't I not need to disable it again in the code part, or comment it out cache related parts, even though it's disabled in CubeMX?

[embeddedCrawler]

Additionally, we tested this scenario on the STM32H757I-EVAL Evaluation board (using only the Cortex-M7 core) and observed that the problem did not occur.

Given that the STM32H743 and STM32H757 share the same Cortex-M7 processor architecture, why might this issue not be present on the latter?

Should the problem be approached as a hardware issue or a software issue?

Is there a possibility of a production-related difference or issue between the two microcontrollers, despite their identical architectures?

 

[mƎALLEm]

Hello @embeddedCrawler ,

Sorry, are you working together (with @ahmetufukgok )?

If yes, the OP has accepted the solution. 

@ahmetufukgok do you confirm you accepted the solution and you have solved the issue?

[ahmetufukgok]

We are working together just wanted to add different point of view to the problem. On the other hand i did not accepted the solution btw. 

[Adam BERLINGER]

I think the problem is that after power-on reset, there are random/noise data inside the Cortex-M7 cache. The cache itself has ECC (error correction code), so any operation that is not "Invalidate all" may result in ECC error. This is error is propagated to BusFault or HardFault handler (I haven't tested).

Calling the SCB_InvalidateDCache function during initialization should solve this issue. I assume calling SCB_DisableDCache might do the same job.

Or you can remove the cache maintenance operations as proposed by @mƎALLEm .

[ahmetufukgok]

 

---

@Adam BERLINGER wrote:

I think the problem is that after power-on reset, there are random/noise data inside the Cortex-M7 cache. The cache itself has ECC (error correction code), so any operation that is not "Invalidate all" may result in ECC error. This is error is propagated to BusFault or HardFault handler (I haven't tested).

Calling the SCB_InvalidateDCache function during initialization should solve this issue. I assume calling SCB_DisableDCache might do the same job.

---

Thank you for response back to me. I suspect that might be the cause and I will test it. However, another problem is that it only works with the current specific LwIP configurations. I get an error again when I turn off the Speculation default mode. What could be the reason for this?

Why would it work on the STM32H757I-EVAL Evaluation board even when I turn almost every setting off, but here it only works in a very specific configuration?

Could you please share a technical document that includes the LwIP advanced options settings( @mƎALLEm @Adam BERLINGER  )?

 

[ahmetufukgok]

we are running an research and need an answer for that. Thus if it is possible, an extra technical document that includes the LwIP advanced options. @mƎALLEm @Adam BERLINGER 

[ABaus]

Is there any update on this? We have the exact same problem.
@Adam BERLINGER I thought it would be best practice to disable Cache at least for ETH regions? Would you suggest keeping it on, as cache coherency is handled internally already?

[mcayir]

I am experiencing the same issue with the following versions:

• STM32CubeIDE 1.19.0

• STM32CubeMX 6.16.0

• STM32CubeH7 Firmware Package V1.12.0

@Adam BERLINGER, will there be an update regarding this?

Additionally, an updated guide on Ethernet + LwIP for the STM32H7 family would be very beneficial for the entire community.