Problems after migrating STM32F777 to new ethernet driver in CubeMX 6.6.1

SStor · ‎2022-09-26

I tried to update an existing and working STM32F7 project to the new ethernet driver.

(MCU STM32F777BIT6 / STM32Cube FW_F7 V1.17.0 / CubeMX 6.6.1)

But there are some problems with this new driver:

1. A Bug in generated function "ethernet_link_thread" in module "ethernetif.c": ETH not started with interrupt

void ethernet_link_thread(void const * argument)
{
:
    if(linkchanged)
    {
      /* Get MAC Config MAC */
      HAL_ETH_GetMACConfig(&heth, &MACConf);
      MACConf.DuplexMode = duplex;
      MACConf.Speed = speed;
      HAL_ETH_SetMACConfig(&heth, &MACConf);      
      // [BUG]
      // ETH not startet with enabled interrupt
      // same start procedure in function low_level_init is correct, but correct function is important at this place!
      //HAL_ETH_Start(&heth);
      HAL_ETH_Start_IT(&heth);
      netif_set_up(netif);
      netif_set_link_up(netif);
    }
:
}

2. A Bug in generated function "low_level_output" in module "ethernetif.c": return code of transmit function not evaluated and following while loop runs into deadlock after error

static err_t low_level_output(struct netif *netif, struct pbuf *p)
{
:
  // [BUG]
  // returncode of function HAL_ETH_Transmit_IT is not evaluated
  // so on error the following while loop runs into a deadlock!
  HAL_ETH_Transmit_IT(&heth, &TxConfig);
  while(osSemaphoreWait(TxPktSemaphore, TIME_WAITING_FOR_INPUT)!=osOK)
 
  {
  }
 
  HAL_ETH_ReleaseTxPacket(&heth);
 
  return errval;
}

3. After starting ETH a fatal bus error occurs in ETHDMA - probably the DMA descriptors are configured incorrect for STM32F7 (copy and paste from STM32H7 with different behaviour?)

4. An user PHY cannot be configured anymore - advanced parameters tab for ETH was removed and on LWIP tab only DP83848 can be selected (I use KSZ8091 on custom board and have to be modify the generated DP83848 files). I think PHY configuration should be a part of ETH interface and not of mid level LWIP.

Why was this changed in new CubeMX?

So I will keep my old working legacy driver because the new driver hasn't reached a sufficient maturity.

I don't know why the new ethernet "improved" driver in current state was released for STM32F7 with CubeMX?

Sara BEN HADJ YAHYA · ‎2022-09-30

Hello @SStor ,

Thanks for your feedback,

There is indeed a new ETH implementation which led to some changes in CubeMX.

Regarding points 1 and 4, your are right and I submitted an internal ticket to be reviewed and fixed by the development team.

Internal ticket number: 135585 (This is an internal tracking number and is not accessible or usable by customers).

About point 2, the error seems to be caused by the missing configuration of DMA Rx and Tx buffers.

The following screenshot is the output of the the FW example that is placed under :

C:\Users\<UserName>\STM32Cube\Repository\STM32Cube_FW_F7_V1.17.0\Projects\STM32F767ZI-Nucleo\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS.

Please check your configuration and if you face any issue, don't hesitate to get back to me. It would be also helpful if you share your project so that we can help you solve the issue.

For the 3rd point, low_level_output function cannot run into deadlock since the second argument of the osSemaphoreWait is the Timeout:

int32_t osSemaphoreWait (osSemaphoreId semaphore_id, uint32_t millisec)

I hope this helps !

Sara.

SStor · ‎2022-10-03

Hello @Sara BEN HADJ YAHYA,

Thank you for your answer.

Please consider also these additional remarks for the points above:

2. A Bug in generated function "low_level_output" in module "ethernetif.c": return code of transmit function not evaluated and following while loop runs into deadlock after error

HAL_ETH_Transmit_IT(&heth, &TxConfig);
while(osSemaphoreWait(TxPktSemaphore, TIME_WAITING_FOR_INPUT)!=osOK)
{
}

The timeout variable TIME_WAITING_FOR_INPUT is set to 0xFFFFFFFF (INFINITE). So this will run into a deadlock on previous errors indeed.

This would be better style:

  errval = HAL_ETH_Transmit_IT(&heth, &TxConfig);
  if (errval == HAL_OK)
  {
    while(osSemaphoreWait(TxPktSemaphore, TIME_WAITING_FOR_INPUT)!=osOK)
    {
    }
  }

3. After starting ETH a fatal bus error occurs in ETHDMA - probably the DMA descriptors are configured incorrect for STM32F7

I've compared my autogenerated CubeMX project with your given example project. It seems to be a problem with cache configuration. With disabled D cache there is no Fatal Bus Error (FBE).

In your example in MPU some ETH memory areas was configured with disabled cache manually. In CubeMX this MPU configuration is missing and clean/invalidate cache functions are not implemented completely. So the autogenerated by CubeMX code is wrong.

I've attached a modified file ethernetif.c, that works for me now.

placing ETH descriptors in DTCMRAM (without cache)
set MEM_ALIGNMENT in lwiopts.h to 32 bytes for cache alignment
calling SCB_CleanDCache() in function low_level_output (better only cleaning single variables/buffers with SCB_CleanDCache_by_Addr, but not sure which)

But all the changes in ethernetif.c will be lost with next CubeMX regeneration.

Maybe it helps to revise this file.

Pavel A. · ‎2022-10-04

placing ETH descriptors in DTCMRAM (without cache)

Ethernet DMA can access DTCMRAM of STM32F7? That's interesting.

SStor · ‎2022-10-04

At least DTCMRAM works for descriptor variables and should be an efficient way to avoid cache handling without performance loss:

// Place Rx and Tx buffers and TxConfig in DTCMRAM (DTCM needs no additional cache handling)
#pragma location=0x20000000
ETH_DMADescTypeDef  DMARxDscrTab[ETH_RX_DESC_CNT]; /* Ethernet Rx DMA Descriptors */
#pragma location=0x200000a0
ETH_DMADescTypeDef  DMATxDscrTab[ETH_TX_DESC_CNT]; /* Ethernet Tx DMA Descriptors */

For other ETH buffers I've not enough space in DTCMRAM unfortunately.

But in legacy ethernetif.c I've placed all ETH descriptor and buffer variables in DTCMRAM without any problems:

("DTCMRAM" symbol is linker defined memory area 0x20000000-0x2001FFFF with 128kB)

/* USER CODE BEGIN 1 */
#pragma default_variable_attributes = @ "DTCMRAM"
/* USER CODE END 1 */
 
/* Private variables ---------------------------------------------------------*/
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
  #pragma data_alignment=4
#endif
__ALIGN_BEGIN ETH_DMADescTypeDef  DMARxDscrTab[ETH_RXBUFNB] __ALIGN_END;/* Ethernet Rx MA Descriptor */
 
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
  #pragma data_alignment=4
#endif
__ALIGN_BEGIN ETH_DMADescTypeDef  DMATxDscrTab[ETH_TXBUFNB] __ALIGN_END;/* Ethernet Tx DMA Descriptor */
 
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
  #pragma data_alignment=4
#endif
__ALIGN_BEGIN uint8_t Rx_Buff[ETH_RXBUFNB][ETH_RX_BUF_SIZE] __ALIGN_END; /* Ethernet Receive Buffer */
 
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
  #pragma data_alignment=4
#endif
__ALIGN_BEGIN uint8_t Tx_Buff[ETH_TXBUFNB][ETH_TX_BUF_SIZE] __ALIGN_END; /* Ethernet Transmit Buffer */
 
/* USER CODE BEGIN 2 */
#pragma default_variable_attributes =
/* USER CODE END 2 */

Results in following map file:

Rx_Buff                 0x2000'bd50      0x17d0  Data  Gb  ethernetif.o [2]
Tx_Buff                 0x2000'd520      0x17d0  Data  Gb  ethernetif.o [2]
DMARxDscrTab            0x2000'ecf0        0x80  Data  Gb  ethernetif.o [2]
DMATxDscrTab            0x2000'ed70        0x80  Data  Gb  ethernetif.o [2]

Piranha · ‎2022-10-30

There are much bigger problems with the code reported in this topic.

1) https://community.st.com/s/question/0D53W00001sGiChSAK/cubemx-lwip-ethernetlinkthread-bug

2) https://community.st.com/s/question/0D53W00001oImr4SAC/bug-stm32-lwip-ethernet-driver-tx-deadlock

And just in case...

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

Piranha · ‎2022-10-30

Yes, it can be seen in AN4667, "Figure 1. STM32F7 Series system architecture". AHBS bus of the CPU core, which has access to TCM memories, is connected to AHB bus masters. On H7 the AHBS bus is connected to MDMA, therefore only that peripheral can access TCM memories.

Sara BEN HADJ YAHYA · ‎2023-01-06

Hello @SStor ,

The issue described in point 1 is fixed in CubeMX v6.7.0, you can download the latest version from st.com website.

About the advanced parameter tab (point 4), it is no longer available and this change is made according to the new ETH implementation.

Sara.