search

STMicroelectronics / STM32CubeH7

STM32Cube MCU Full Package for the STM32H7 series - (HAL + LL Drivers, CMSIS Core, CMSIS Device, MW libraries plus a set of Projects running on all boards provided by ST (Nucleo, Evaluation and Discovery Kits))
https://www.st.com/en/embedded-software/stm32cubeh7.html
Other
490 stars 302 forks source link

Full rework of Ethernet HAL driver #195

Closed ALABSTM closed 2 years ago

ALABSTM commented 2 years ago

The reworked Ethernet HAL driver brings multiple changes and a compatibility break vs. previous Ethernet HAL driver. Main changes are listed here:

Jovan-ux commented 2 years ago

Hi ALABSTM, Thank you for your Support and provided src. Finally got this integrated. Your rework seems very promising. Thx for examples anyway. Throughput also looks very, very good. Will give you feedback about stability ASAP. For 2022 for you all the best, KR Jo

ALABSTM commented 2 years ago

Hi @holden-zenith,

Thank you for this review.

With regards,

MichaelStrohmeier commented 2 years ago

Hi, if USE_HAL_ETH_REGISTER_CALLBACKS == 1 is used, the new callbacks (RxAllocateCallback, RxLinkCallback, TxFreeCallback, TxPtpCallback) are not set to their defaults in ETH_InitCallbacksToDefault. Is this desired?

pjukica commented 2 years ago

Hi, Is the update of all projects which revolve around Ethernet HAL driver planned in this merge request? There are some examples which aren't updated so I was wondering if that was intentional. For example, mbedTLS projects which utilize FreeRTOS, LwIP and mbedTLS haven't been updated: https://github.com/ALABSTM/STM32CubeH7/tree/master/Projects/STM32H743I-EVAL/Applications/mbedTLS

Will this be updated soon?

ALABSTM commented 2 years ago

Hi @MichaelStrohmeier and @pjukica,

Thank you for your questions. They have been forwarded to our development teams. We will get back to you as soon as we get their answers.

With regards,

ALABSTM commented 2 years ago

Hi @pjukica,

There are some examples which aren't updated [...] For example, mbedTLS projects which utilize FreeRTOS, LwIP and mbedTLS

Actually, there is no plan to update such applications. These are intended to keep using previous ETH HAL driver which will be moved to both stm32h7xx_hal_driver\Inc\Legacy and stm32h7xx_hal_driver\Src\Legacy folders.

With regards,

ALABSTM commented 2 years ago

Hi @MichaelStrohmeier,

if USE_HAL_ETH_REGISTER_CALLBACKS == 1 is used, the new callbacks (RxAllocateCallback, RxLinkCallback, TxFreeCallback, TxPtpCallback) are not set to their defaults in ETH_InitCallbacksToDefault. Is this desired?

We confirm this is not intended . A fix will be made available in a future release. Thank you for having reported the point.

With regards, Ali

ktrofimov commented 2 years ago

The legacy driver (Cube MCU for H7 v.1.9.1) was working for me except for situations with high network traffic. Then HAL_ETH_Transmit() exited with errors HAL_ETH_ERROR_BUSY and/or HAL_ETH_ERROR_TIMEOUT and then the network failed because no transmission was possible. Simply increasing the number of DMA descriptors from 4 to 16 did not help. But changing send functions from HAL_ETH_Transmit() to HAL_ETH_Transmit_IT() did the thing. Ethernet now works more stable. Thank you for your work!

dima-kapustin commented 2 years ago

Hi, @ktrofimov , what is the high traffic in mb/s, please?

ALABSTM commented 2 years ago

Hi @ktrofimov,

But changing send functions from HAL_ETH_Transmit() to HAL_ETH_Transmit_IT() did the thing. Ethernet now works more stable. Thank you for your work!

Glad to read this new ETH HAL driver helped you overcome that issue.

With regards,

ktrofimov commented 2 years ago

what is the high traffic in mb/s, please?

Sorry, did not measure traffic yet - MCU serves a simple HTTP server, plus some additional services like SSDP, Modbus TCP... As a test, I did use several console apps: ping, curl index.html, ssdp discovery, and libmodbus client requesting 10 holding registers making requests every second. The original driver fails in a couple of hours. If there is no pause in between Modbus queries then it might fail faster. - in a few minutes. With updated Tx functions no failures yet. Will put on a long test.

dima-kapustin commented 2 years ago

I have outgoing UDP traffic about 48 Mb/s and release build fails with HAL 1.10 rather quickly. Debug build runs with no issues, however I cannot say what throughput I get then.

Based on your comment, I may need to try interrupt version of the TX function.

Thanks

ktrofimov commented 2 years ago

overcome that issue

Not really... More tests show that HAL_ETH_Transmit_IT() still fails, but now with the error HAL_ETH_ERROR_BUSY at function call ETH_Prepare_Tx_Descriptors(heth, pTxConfig, 1)

As soon I add the SSDP multicast announcement some (but not all) data communication failed in a few minutes. Probably some bugs in reception. Sometimes ping can get an ICMP reply with a delay of several seconds (which seems very strange to me):

Request timeout for icmp_seq 66
Request timeout for icmp_seq 67
Request timeout for icmp_seq 68
Request timeout for icmp_seq 69
64 bytes from 192.168.2.9: icmp_seq=66 ttl=255 time=4079.790 ms
Request timeout for icmp_seq 71
Request timeout for icmp_seq 72
Request timeout for icmp_seq 73
64 bytes from 192.168.2.9: icmp_seq=67 ttl=255 time=7376.429 ms
64 bytes from 192.168.2.9: icmp_seq=68 ttl=255 time=6474.035 ms
64 bytes from 192.168.2.9: icmp_seq=75 ttl=255 time=0.345 ms
Request timeout for icmp_seq 77
Request timeout for icmp_seq 78

Same delays I have noticed when tried to implement the new driver in full (now only sending functions are taken from the new driver).

Current lwIP config (should be enough for all current simultaneous connections): /----- Default Value for MEMP_NUM_UDP_PCB: 4 ---/

define MEMP_NUM_UDP_PCB 10

/----- Default Value for MEMP_NUM_TCP_PCB: 5 ---/

define MEMP_NUM_TCP_PCB 20

Attachments: ip_failure.pcapng.zip

ping_failure

P.S. Driver continues to send and receive packets, but there are lots of TCP retransmissions. It looks for me now as lwIP stack problem.

ktrofimov commented 2 years ago

Debug shows that no space in PBUF left, but still, right after that HAL_ETH_Transmit_IT() I've got an error HAL_ETH_ERROR_BUSY. Only once, but it happened.

Update: increasing PBUFs size and count did not help. What really helped - increasing tcpip_thread priority from osPriorityNormal (24) to osPriorityNormal4 (28). Besides this task, there are about a dozen other ones with the same osPriorityNormal (like Network, Modbus, TouchGFX and others)

Update 2: The thread priority fix gave just a little extra time. The issue is not fixed.

ktrofimov commented 2 years ago

I've got an error HAL_ETH_ERROR_BUSY. Only once, but it happened

Google for this problem I did found a possible solution both for Tx and Rx:

static err_t low_level_output(struct netif *netif, struct pbuf *p)
{
    . . .
    res = HAL_ETH_Transmit_IT(&heth, &TxConfig );
    if( res != HAL_OK )
    {
        printf(“%s: HAL_ETH_Transmit failed, errorcode: %lx\n”, __func__, HAL_ETH_GetError(&heth));

        // Clear TBU flag to resume processing
        heth.Instance->DMACSR = ETH_DMACSR_TBU;
        // Instruct the DMA to poll the transmit descriptor list
        heth.Instance->DMACTDTPR = 0;
    }
    . . .
}

and

void ethernetif_input(void* argument)
{
    struct pbuf *p;
    struct netif *netif = (struct netif *) argument;

    for( ;; )
    {
        if (osSemaphoreAcquire(RxPktSemaphore, TIME_WAITING_FOR_INPUT) == osOK)
        {
            do
            {
                p = low_level_input( netif );
                if (p != NULL)
                {
                    if (netif->input( p, netif) != ERR_OK )
                    {
                        pbuf_free(p);
                    }
                }
            } while(p!=NULL);
        }
        if( (heth.Instance->DMACSR & ETH_DMACSR_RBU) != (uint32_t)RESET)
        {
            // Clear RBUS ETHERNET DMA flag
            heth.Instance->DMACSR = ETH_DMACSR_RBU;
            // Resume DMA reception. The register doesn’t care what you write to it.
            heth.Instance->DMACRDTPR = 0;
        }
    }
}
ALABSTM commented 2 years ago

Hi @dima-kapustin and @ktrofimov,

Thank you for sharing your interesting findings. In case some issue is confirmed from your side, please do not hesitate to file a new issue or pull-request. This would ease the tracking as this pull-request has been merged and is now considered as closed.

With regards,

VanshajKaistha commented 2 years ago

Hi @ALABSTM,

I am trying to configure my STM32H743XIHx Eval board for ethernet without DHCP and using CMSIS_V2, code was being compiled properly but i am not able to ping my device. I am new to it if anyone can guide me, I will be happy to learn.

Thanks

ALABSTM commented 2 years ago

Hi @dima-kapustin and @ktrofimov,

Thank you for sharing your interesting findings. In case some issue is confirmed from your side, please do not hesitate to file a new issue or pull-request. This would ease the tracking as this pull-request has been merged and is now closed.

With regards,

ALABSTM commented 2 years ago

Hi @VanshajKaistha,

Would you mind submitting your request to the ST Community under the STM32H7 topic page. There you might find the support you are looking for.

Indeed, this channel is solely dedicated to topics directly related to the software delivered within this repository, as indicated in the CONTRIBUTING.md guide. Thank you for your comprehension.

With regards,

erwango commented 1 year ago

For interested readers, complementary information could be found here: https://community.st.com/s/question/0D53W00001Gi9BoSAJ/ethernet-hal-driver-reworked-by-st-and-available-in-22q1-preview-now-available-on-github