FreeRTOS+TCP with no PHY

Dweb_2 · February 22, 2022, 7:25am

Hi,
we are using a RTOS+TCP V2.3.3 port for a STM32H7 which works very well so far. However due to the semiconductor shortage we could not assemble ethernet PHYs on our boards.
We lately started to use the ITCM with MPU protection, and debugging revealed that this lead to hard faults from the network stack side.
NULL was accessed from some descriptor fields here:

github.com

FreeRTOS/FreeRTOS-Plus-TCP/blob/d425fbd70cb9459f4b9f722668be8cf6de42f75d/portable/NetworkInterface/STM32Hxx/stm32hxx_hal_eth.c#L753

      
        
            
            
            if( ( pBuffer1 == NULL ) || ( Index >= ( uint32_t ) ETH_RX_DESC_CNT ) )
                        {
                            /* Set Error Code */
                            heth->ErrorCode = HAL_ETH_ERROR_PARAM;
                            /* Return Error */
                            return HAL_ERROR;
                        }
            
            
            /* write buffer address to RDES0 */
                        WRITE_REG( dmarxdesc->DESC0, ( uint32_t ) pBuffer1 );
                        /* store buffer address */
                        WRITE_REG( dmarxdesc->BackupAddr0, ( uint32_t ) pBuffer1 );
                        /* set buffer address valid bit to RDES3 */
                        SET_BIT( dmarxdesc->DESC3, ETH_DMARXNDESCRF_BUF1V );
            
            
/*  Not used for FreeRTOS+TCP */
            /*	if(pBuffer2 != NULL) */
            /*	{ */
            /*		/ * write buffer 2 address to RDES1 * / */
            /*		WRITE_REG(dmarxdesc->DESC2, (uint32_t)pBuffer2); */

The HAL ETH Init failed, and did not set some pointers to their proper values. I’m wondering why the return value of the HAL is ignored here:

github.com

FreeRTOS/FreeRTOS-Plus-TCP/blob/d425fbd70cb9459f4b9f722668be8cf6de42f75d/portable/NetworkInterface/STM32Hxx/NetworkInterface.c#L232

      
        
            xEthHandle.Init.MACAddr = ( uint8_t * ) FreeRTOS_GetMACAddress();
            xEthHandle.Init.MediaInterface = HAL_ETH_RMII_MODE;
            xEthHandle.Init.TxDesc = DMATxDscrTab;
            xEthHandle.Init.RxDesc = DMARxDscrTab;
            xEthHandle.Init.RxBuffLen = ( ETH_RX_BUF_SIZE - ipBUFFER_PADDING ) & ~( ( uint32_t ) 3U );
            
            
/* Make sure that all unused fields are cleared. */
            memset( &( DMATxDscrTab ), '\0', sizeof( DMATxDscrTab ) );
            memset( &( DMARxDscrTab ), '\0', sizeof( DMARxDscrTab ) );
            
            
xHalEthInitStatus = HAL_ETH_Init( &( xEthHandle ) );
            
            
/* Only for inspection by debugger. */
            ( void ) xHalEthInitStatus;
            
            
/* Configuration for HAL_ETH_Transmit(_IT). */
            memset( &( xTxConfig ), 0, sizeof( ETH_TxPacketConfig ) );
            xTxConfig.Attributes = ETH_TX_PACKETS_FEATURES_CRCPAD;
            
            
#if ( ipconfigDRIVER_INCLUDED_TX_IP_CHECKSUM != 0 )
                {

Is there any way we can safely shut down the network stack? Are there any reasons xHalEthInitStatus is unused?

Thanks for your help!

kanherea · February 22, 2022, 5:38pm

Hello @Dweb_2,

I am not entirely sure why was the return ignored. However, you should be able to get around this problem by checking for errors. Thus, if you add the below edits here, then it should work.

@@ -234,6 +234,8 @@ BaseType_t xNetworkInterfaceInitialise( void )
        /* Only for inspection by debugger. */
        ( void ) xHalEthInitStatus;

+      if( xHalEthInitStatus == HAL_OK )
+      {
            /* Configuration for HAL_ETH_Transmit(_IT). */
            memset( &( xTxConfig ), 0, sizeof( ETH_TxPacketConfig ) );
            xTxConfig.Attributes = ETH_TX_PACKETS_FEATURES_CRCPAD;
@@ -299,6 +301,11 @@ BaseType_t xNetworkInterfaceInitialise( void )
            {
                xMacInitStatus = eMACFailed;
            }
        }
+       else
+       {
+          xMacInitStatus = eMACFailed;
+       }
    } /* ( xMacInitStatus == eMACInit ) */

Let me know if that works for you.

Thanks,
Aniruddha

Dweb_2 · February 23, 2022, 6:53am

Hi,
thanks for your quick response! This snippet seems to have solved the issue.
Is there a chance this fix will be included in future versions of the STM32H7 port for FreeRTOS+TCP?
Many thanks, Aniruddha!

Dweb_2 · March 2, 2022, 6:09am

@kanherea do you think this would be possible?

htibosch · March 2, 2022, 7:01am

Is there a chance this fix will be included in future versions of the STM32H7 port for FreeRTOS+TCP?

Sure that is possible. If you like, you can create a pull-request your self, in case we can help you with the details.

It is also possible that Aniruddha or I prepares a PR to change the driver.

Thanks

Dweb_2 · March 2, 2022, 8:11am

Thanks @htibosch for your quick response! Honestly I’m not really familiar with GitHub

htibosch · May 12, 2022, 3:06pm

@Dweb_2, I finally created a PR for the above issue, see PR #465

I don’t the proper hardware at my present location, and I would be glad if you can do a test.

Dweb_2 · May 13, 2022, 5:46am

Thanks @htibosch. In the meantime we could assemble the missing PHY. I would need to de-solder the component to test it again.

htibosch · May 13, 2022, 8:19pm

I would need to de-solder the component to test it again.

Oops, please don’t. Just compile and run the application if you like, that would be fine. Thanks, Hein

Dweb_2 · October 20, 2023, 10:28am

Hi, sorry for reopening this. Could you check if the proposed changes from this thread (respectively this PR: IPv4/single: STM32H7xx driver check result of HAL_ETH_Init by AniruddhaKanhere · Pull Request #479 · FreeRTOS/FreeRTOS-Plus-TCP · GitHub) are currently properly in the main branch/release? Looks to me like some commit in the past reverted it again (see my comment on github).

ActoryOu · October 21, 2023, 12:39pm

Hi @Dweb_2,
Thanks for reporting this to us. That commit seems got reverted by mistake.
Would you like to contribute a PR to fix it? Or I can raise PR to fix it.

Thanks!

htibosch · October 23, 2023, 3:06am

I will check what has happened to mentioned PR, and create a new PR for it.
Thanks for reporting

ActoryOu · October 24, 2023, 7:28am

Hi @Dweb_2,
Note that PR#1035 has been created by @htibosch. It’s now under verifying. Feel free to leave your comment on it.

Thanks.

Edit: PR has been merged

htibosch · October 30, 2023, 5:02am

The problem got solved about a week ago in PR #1035: “STM32H7xx driver check result of HAL_ETH_Init v3”.