Problem related to the STM32H7 IP Stack (STM32H743ZITx) : break of UDP communication

[Bajocasse]

We notice, after a certain time, a totaly break of UDP/IP communication (LwIP layer) of our STM32H7 project (FreeRTOS layer is also used).
This stop occurs without any particular external condition and generally after a fairly long time (after a few hours).
No more frames are then transmitted (by UDP client in particular) nor received in the Callback function (UDP server).
This break of communication is never followed by a resumption of communication, but a program reset systematically allows good communication to be restored.

What could this possibly be due to?
Could we have configured an element incorrectly?

is there a bug in the Ethernet or LwIP layers?

[STea]

Hello @Bajocasse ,

can you please confirm the version of Firmware you are using.

as there was some issue solved with the new driver which had similar issues as the one you are describing.

another way to look at it the MPU configuration which can be the source of your issue. 

I would like to know as well how you are managing the received backets in your code to further help you to know what's what.

BR

[Bajocasse]

Hi STea,

here are the versions of the different software components used in the project

Additionally, I read another interesting post on this topic ([BUG] STM32 lwIP Ethernet driver Tx deadlock) which seems to match my problem.

So I was thinking of making the following 2 corrections in the ethernetif.c file.

In "low_level_init" function :

replace

RxPktSemaphore = osSemaphoreNew(1, 1, NULL);

by

RxPktSemaphore = osSemaphoreNew(1, 0, NULL); // correction

and in "low_level_output" function :

replace

HAL_ETH_Transmit(&heth, &TxConfig, ETH_DMA_TRANSMIT_TIMEOUT);

by

if (HAL_ETH_Transmit(&heth, &TxConfig, ETH_DMA_TRANSMIT_TIMEOUT) != HAL_OK)

{

pbuf_free(p); // bug fix?

}

Does this seem like a good idea to you?

 

To receive packets, I used callback function and stack data like that

static void UDP_receive_callback(void *arg, struct udp_pcb *upcb, struct pbuf *p, const ip_addr_t *addr, u16_t port)
{

AddrReceived = *addr;
PortReceived = port;

MODBUS_SRV_StackUdpBufferReceived (p->payload, p->len);
/* Free the pbuf buffer */
pbuf_free(p);

}

 

To transmit packets, I used this function

void UDP_Modbus_Server_send_buffer (uint8_t * DataToSend, uint16_t DataLength)
{

struct pbuf *txBuf;

if (UDP_CableEthConnected == true)
{

/* allocate pbuf from RAM*/
txBuf = pbuf_alloc(PBUF_TRANSPORT, DataLength, PBUF_RAM);

/* copy the data into the buffer */
pbuf_take(txBuf, DataToSend, DataLength);

/* Connect to the remote client */
if (udp_connect(pUdpModbusServerPcb, &AddrReceived, PortReceived) != (err_t)ERR_OK)
{
// no action
}

/* Send a Reply to the Client */
if (udp_send(pUdpModbusServerPcb, txBuf) != (err_t)ERR_OK)
{
// no action
}

/* free the UDP connection, so we can accept new clients */
udp_disconnect(pUdpModbusServerPcb);

/* Free the pbuf buffer */
pbuf_free(txBuf);

}

}

you can see my source code in the attached files

[Bajocasse]

unfortunately the corrections that I propose do not correct the problem. I have once again had a communication cutoff after ~5 hours of continuous correct communication

[Pavel A.]

@Bajocasse Also, are you using the driver from FreeRTOS+ Net?

 

[Bajocasse]

No, I do not think so

[STea]

Hello @Bajocasse  ,

I reported the issue internally as it is needing further investigation.

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

Thank you.

[Bajocasse]

the bug seems to be fixed in the release "STM32CubeH7 Firmware Package V1.11.0 / 04-Nov-2022".

So I update my firmware with the latest version "STM32CubeH7 Firmware Package V1.11.2 / 15-March-2024"

(see https://github.com/STMicroelectronics/STM32CubeH7/issues/224).

 

For the moment it works well with this version but there are some operating deviations. The most worrying is some firmware versions (minor modifications) generate a HardFault_Handler for no reason upon startup.

However, the MPU is well configured according to the recommendations of the post

https://community.st.com/t5/stm32-mcus/how-to-create-project-for-stm32h7-with-ethernet-and-lwip-stack/ta-p/49308 

But by deactivating the D-Cache memory (in MCU init), it starts working again !

Could there be a problem at this level?

Is it okay to disable D-Cache for this to work?

What bothers me is that we use the LwIP layer and normally STM32CubeMX deactivates this LwIP module if we deactivate the D-Cache.

Can we still make the LwIP layer work without D-Cache without problems?