FAQs
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

STM32H563 NetxDuo Packet Pool Deadlock

stst9180
Associate III

‎2024-09-16 03:37 AM

Hi Community,
I'm currently facing an issue where NetXDuo with the STM32H563 locks itself out if the packet pool runs out of packets. In the current szenario the problem occurs when using the ftp-server addon and retriving  a file. As the chunks are posted to the tcp stack very fast, the socket_send routine returns success, but packets are not released (as they are currently not sent by the stack -> normal behaviour)
But if this happens to fast, the packet pool runs empty (which may also be an ok behaviour here). But then the network driver can't fill up it's rx-descriptors anymore and locks up completely. The packets are never released and a reboot of the device is necessary.

Is this a known issue somwhere? Any Ideas how/ where to debug further?

Labels:
0 Kudos
2 REPLIES 2
stst9180
Associate III

‎2024-09-16 04:06 AM - edited ‎2024-09-16 04:06 AM

I found my self a solution by dividing the packet pool according to:

https://en.na4.teamsupport.com/knowledgeBase/18188850
Nevertheless for my opinion the networking should recover from an empty internal packet pool on the driver side.
I can't find any documentation about how big the internal packet pools needs to be to make sure a deadlock is not possible.

Regards Pascal

 

 

 

0 Kudos
stst9180
Associate III
In response to stst9180

‎2025-01-27 04:53 AM

Hi guys, unfortunately this work-around does not really solve the problem but does only shift it to "seldom occurence". It may still happen that on an occupied system the internal packet pool will exhaust. ( We're currently experiencing this problem with the telnet-addon) as here the internal packets are handled in the telnet-thread. If this one is to slow the internal packet pool will exhaust and never recover. For my opinion NetXDuo should be altered in a way that this situation is really recoverable. Maybe also by killing some sockets or something. This is unfortunately currently not done so the network stays unusable and a manual reboot of the device has to be done.
I currently could not find out why the system isn't recovering as if telnet thread will free the packets l8er, networking should start running again, but there seems to be an issue with the driver which does not do the recover well.

May someone of the ST-Internals have a look on this issue too?

0 Kudos
Top