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()

[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?

[mƎALLEm]

---

@embeddedCrawler wrote:

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

---

STM32H743 is a single core product STM32H757 is a dual core product. From Ethernet stand point there is no differences. So I suspect the issue is in your implementation in single core vs dual core.

[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?

[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. 

[ahmetufukgok]

---

STM32H743 is a single core product STM32H757 is a dual core product. From Ethernet stand point there is no differences. So I suspect the issue is in your implementation in single core vs dual core.

---

We are running the evaliation board only with M7 core. Its not related the dual core.

[mƎALLEm]

Did you test what I suggested above? by uncommenting the related cache functions?

There is no differences at the silicon level from this standpoint. 

[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 .