ARMmbed / mbed-os

Arm Mbed OS is a platform operating system designed for the internet of things
https://mbed.com
Other
4.66k stars 2.97k forks source link

STM32H7 TCP non functional #15429

Open jtmyz9 opened 1 year ago

jtmyz9 commented 1 year ago

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 https://github.com/STMicroelectronics/STM32CubeH7/commit/c94252df7cec24a8fef67b28933353476a1edd3c ), 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 commented 1 year ago

@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 commented 1 year ago

cc @ARMmbed/team-st-mcd

multiplemonomials commented 12 months ago

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 commented 12 months ago

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