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 · Accepted solution]

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.