STM32H7 TCP non functional

[jtmyz9]

Description of defect

TCP connections to the microcontroller cannot be established, seemingly because RX packets are never written to DMA/DMA ownership never given to application.

In core STM32Cube drivers, was a complete rework of ethernet drivers( v1.10.0 STMicroelectronics/STM32CubeH7@c94252d ), that when building off of one of the example projects from cube repo post this rework, TCP connections can be established to the microcontroller.

Most straightforward solution appears to be to uprev the cube driver version for the H7 familiy

Target(s) affected by this defect ?

STM32H745, presumably affects all H7 family chips

Toolchain(s) (name and version) displaying this defect ?

arm-gcc

What version of Mbed-os are you using (tag or sha) ?

6.17

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli

How is this defect reproduced ?

Attempt to connect via TCP socket to the chip.

[mbedmain]

@jtmyz9 thank you for raising this issue.Please take a look at the following comments:

It would help if you could also specify the versions of any tools you are using?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'. This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information.

[0xc0170]

cc @ARMmbed/team-st-mcd

[multiplemonomials]

Funny, I recently ran the TCP test suite on my STM32H743 board and it was able to pass just fine. STM32F7, though, appears to currently have broken networking. This was on my mbed-ce fork though so not sure if anything's different there...

[jtmyz9]

As an extra data point, this did also work just fine on a STM32H743 for me.
The issue appears to be (mostly) with the MPU config on the STM32H745(and any other of the dual core H7 family), where after making some local modifications to \connectivity\drivers\emac\TARGET_STM\stm32xx_emac.cpp for the mpu config to match what it is in some of the H745 examples from stm_cube

+ #ifdef TARGET_STM32H7
+    /* Configure the MPU attributes as Device not cacheable
+    for ETH DMA descriptors */
+    MPU_InitStruct.Enable = MPU_REGION_ENABLE;
+    MPU_InitStruct.BaseAddress = 0x30040000;
+    MPU_InitStruct.Size = MPU_REGION_SIZE_1KB;
+    MPU_InitStruct.AccessPermission = MPU_REGION_FULL_ACCESS;
+    MPU_InitStruct.IsBufferable = MPU_ACCESS_NOT_BUFFERABLE;
+    MPU_InitStruct.IsCacheable = MPU_ACCESS_NOT_CACHEABLE;
+    MPU_InitStruct.IsShareable = MPU_ACCESS_NOT_SHAREABLE;
+    MPU_InitStruct.Number = MPU_REGION_NUMBER0;
+    MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
+    MPU_InitStruct.SubRegionDisable = 0x00;
+    MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;
+
+    HAL_MPU_ConfigRegion(&MPU_InitStruct);
+
+    /* Configure the MPU attributes as Cacheable write through
+       for LwIP RAM heap which contains the Tx buffers */
+    MPU_InitStruct.Enable = MPU_REGION_ENABLE;
+    MPU_InitStruct.BaseAddress = 0x30044000;
+    MPU_InitStruct.Size = MPU_REGION_SIZE_16KB;
+    MPU_InitStruct.Number = MPU_REGION_NUMBER1;
+    MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL1;
+#else
     /* Configure the MPU attributes as Device not cacheable
        for ETH DMA descriptors */
     MPU_InitStruct.Enable = MPU_REGION_ENABLE;
@@ -233,6 +258,7 @@ static void MPU_Config(void)
     MPU_InitStruct.TypeExtField = MPU_TEX_LEVEL0;
     MPU_InitStruct.SubRegionDisable = 0x00;
     MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;
+#endif

[multiplemonomials]

This issue should now be fixed in Mbed CE, we rewrote the Ethernet drivers for STM32 from the ground up: mbed-ce#438 . If you still have any Ethernet issues using master branch of Mbed CE, let me know and I will see what we can do!