Sending UDP on NetXDuo does not work without breakpoints.

[Hey0256]

Hi, I have created a program to send UDP using NetXDuo on a Nucleo-H755ZI.
I used the URL below as a reference.

Creating a dual IPv6 & IPv4 NetXDuo UDP application for STM32H7 using CubeMX

 

I checked the operation in debug mode and could see that it is sending UDP with Wireshark.

However, when I unchecked “Set breakpoint at:main” in the debug properties and checked without breakpoints, no UDP was sent.

The version of STM32CudeIDE is 1.18.0, X-CUBE-AZRTOS-H7 version is 3.3.0.

How can I send UDP in debug mode without breakpoints or send UDP in RUN mode?

If anyone has a solution, please let me know.

 

STM32H755ZITX_FLASH.ld could not be uploaded, but the following memory is allocated.

 .tcp_sec (NOLOAD) : 
 {
 . = ABSOLUTE(0x24030000);
 *(.RxDecripSection)

 . = ABSOLUTE(0x24030080);
 *(.TxDecripSection)
 
 . = ABSOLUTE(0x24030200);
 *(.NetXPoolSection)
	
 } >RAM_D1 AT> FLASH

 

[Andrew Neil]

---

@Hey0256 wrote:

when I unchecked “Set breakpoint at:main” in the debug properties and checked without breakpoints, no UDP was sent.

---

Sounds like there's something you need to wait for at the start of main...

 

https://community.st.com/t5/stm32-mcus-embedded-software/stm32f767-lwip-tcp-client/m-p/777886

[Hey0256]

Dear Neil.
Thank you for your reply.

I was surprised to see that the problem is not only a NetDuo problem, but also happens with LWIP.
I also tried updating the Ethernet status with nx_ip_interface_status_check and nx_ip_driver_direct_command, but it did not work.
In the end, adding HAL_Delay(2000) before MX_ThreadXInit() in main.c was a sure thing.
Thanks to your advice, I am now able to send UDP without any problems.
I hope this note of mine will help others.
Thank you again.

[Andrew Neil]

---

@Hey0256 wrote:

I was surprised to see that the problem is not only a NetDuo problem, but also happens with LWIP..

---

Which certainly suggests that the "problem" is just that something (presumably hardware?)  takes a while to "stabilise" - and you just have to wait for that to complete.

 

What this really needs is someone to look into it and find what, exactly, that thing is - and, thus, how to check for "ready" without just resorting to arbitrary, blind delays.

@ASEHST  ?

[ASEHST]

Hello,

This recurring issue has been tracked internally.

An internal ticket (212424) has already been raised for follow-up.

 

With Regards.

[bouazizm]

Hello,

During the initialization process, the ETH MAC must be configured with the correct Ethernet link speed and duplex mode after the auto-negotiation process is completed, which can take up to a few seconds (see the API HAL_ETH_SetMACConfig).

To resolve the issue, please add the task App_Link_Thread_Entry to your app_netxduo.c file (refer to Nx_TCP_Echo_Client example from X-CUBE-AZRTOS-H7 v3.3.0) .

This task continuously polls the PHY status and updates the MAC configuration if any changes occur to the Ethernet link.

Note: There is no need to add an additional HAL_delay().

Regards