2024-09-03 11:37 AM
Hi all,
We have an STM32H735VGH6 on a custom board with a LAN8742a PHY chip to allow ethernet communication. This custom board is minimally tested so it's possible that there's a hardware issue though I'm uncertain where the issue would be. I generated the MCU project using STM32CubeMX (ver 6.12.0) and have been running it with STM32CubeIDE (version 1.16.0). In all versions that I'm running, the MPU is setting all 4GB of space to be non-cacheable.
After a lot of playing around with it, I have been able to get communication to work (basic ARP announcement and ICMP responses) but only in two conditions:
1. If I regenerated the MX project but with the D-Cache enabled under "Cortex Interface Settings" (the MPU is still set up with cache disabled). Then running that build (which doesn't work). Then, without powering down, re-generating the build with D-Cache disabled. Running after that would allow the STM32 to respond to incoming packets. I can rebuild as much as I want and it will work so long as I don't shut off the power. If I do shut off the power, despite having flashed the board with that build, if I turn the power back on then it no longer responds to ARP communication. If I then attach the debugger, sometimes though not all the time, it will attempt to read an incoming packet and have a hard fault from attempting to invalidate D-Cache despite D-Cache not being enabled. The invalidate D-Cache function has a define it checks to ensure that D-Cache exists (which is set to 1 in both generated codebases) and if I force that to 0, it gets past the hard fault but it still doesn't respond to packets.
2. The other method to get it to work is to put the "SCB_EnableDCache()" call after the MPU_Config(), but to then add "SCB_DisableDCache()" after the MX_LWIP_Init() function is called (all while the MPU is still not allowing cache access). This will cause all future ethernet connections to work but if the ethernet is plugged in while programming this build or on boot up, the STM32 doesn't respond (until that ethernet is unplugged and replugged in). This makes me think that the Initialization isn't occurring fully successfully. I've tried moving the SCB_DisableDCache() before the MX_LWIP_Init() and it doesn't work. I did not yet try and see at exactly what point inside the MX_LWIP_Init() that the cache needs to be set for the communication to function on future connections.
What could be going on here to cause this issue? I have attached the generated .ioc file in case that helps.
2024-09-03 02:21 PM
It's interesting.
> attempting to invalidate D-Cache despite D-Cache not being enabled.
Do not invalidate D-Cache when it is not enabled (some people say it is a bug in old CMSIS version in ST libraries...) but I always do:
bool dc = !!(SCB->CCR & (uint32_t)SCB_CCR_DC_Msk);
if (dc) {
/* flush or invalidate D cache */
} /* else don't touch d-cache */