STM32F746 Ethernet DMA Transmit problem

Hi,

I've been debugging this for quite a few hours now, wish I had found this thread sooner... Being almost certain that I had done something wrong outside HAL, I've gone through quite a few iterations.

In any case, what I have conluded is that there is likely a race condition in the HAL HAL_ETH_TransmitFrame (stm32f7xx_hal_eth.c, version V1.1.2). I have two projects with the F746, one that 'works' and one that fails to transmit a frame every now and then. The project that works is generated by STM32CubeMX and uses lwIP and the ST supplied driver between lwIP and HAL. Second project which has issues is using FreeRTOS+TCP stack and a modified version of the driver supplied by FreeRTOS written for STM32F4.

In the project that fails I have the I-cache enabled and D-cache disabled on my F746 running at 192MHz, but the default setting in Cube project seems to be to have the ART-accelerator as well as both D and I-caches disabled which slows down things in general which appears to mask this issue.

What appears to be the issue though is that the store instructions the CPU is doing towards the 

T

xDesc resgisters, for example 

if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET)

Note that in the CubeMX project driver, this restart sequence is actually performed twice (one in the HAL driver, and once in the low_level_output() function in ethernetif.c , which also masks this issue.

My 'solution' was to add a synchronization barrier inside the HAL driver, after filling in the TxDesc and before restarting the DMA engine from the suspended state. That appears to solve the problem, but I'm hoping someone at ST can shed some more light on this topic.

//Daniel

Hi,

I guess you could be running into the same issue. It's been quite a while since I reported this, but I haven't seen any response from STs side. These issues are obviously quite hard to debug, and since the HAL code appears to mask them I guess ST testcases still works. Below is my patch to fix my issue, I haven't had a problem in this area since I applied this fix.

Regards

Daniel

diff --git a/fw/controller/system/src/stm32f7-hal/stm32f7xx_hal_eth.c b/fw/controller/system/src/stm32f7-hal/stm32f7xx_hal_eth.c
index 527ed.07eeba0 100644
--- a/fw/controller/system/src/stm32f7-hal/stm32f7xx_hal_eth.c
+++ b/fw/controller/system/src/stm32f7-hal/stm32f7xx_hal_eth.c
@@ -752,7 +752,12 @@ HAL_StatusTypeDef HAL_ETH_TransmitFrame(ETH_HandleTypeDef *heth, uint32_t FrameL
 heth->TxDesc = (ETH_DMADescTypeDef *)(heth->TxDesc->Buffer2NextDescAddr);
 }
 }
- 
+
+ /* DNIL: Sync here before moving on. Otherwise we seem to have intermittent issues with stores to
+ * TxDesc->Status register not reaching the DMA engine.
+ */
+ __DSB();
+
 /* When Tx Buffer unavailable flag is set: clear it and resume transmission */
 if (((heth->Instance)->DMASR & ETH_DMASR_TBUS) != (uint32_t)RESET)
 {
�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?�?

That could be the reason for some, but in my case, I have caches disabled. I am using both the Nucleo-F767 and Nucleo-H743 boards. The CubeMX H7 Ethernet driver puts a call to SCB_CleanDCache() in the driver, but when called, it causes a hard fault. I had to comment it out. The default linker script also places all data into the DTCM section, so there is no caching. The HAL Ethernet drivers for the H7 have some serious issues. I submitted another issue that points out that DHCP cannot work, and I described a simple fix.