Closed mapellil closed 7 months ago
What platform did you use? One solution is to move WIFI connect from network driver to the application.
Thanks for the suggestion, however i do not expect to find a blocking call tx_mutex_get(&(ip_ptr -> nx_ip_protection), TX_WAIT_FOREVER) within a timed API nx_ip_status_check() because, if for any reason the API internal mutex is not released the API also become blocking regardless of the timer specified in the args. My platform is https://www.st.com/en/evaluation-tools/steval-stwinbx1.html. Regards
In Azure RTOS, cost on the mutex waiting is not part of timeout. So it is not likely to change the logic here.
Describe the bug Calling the nx_ip_interface_status_check(,,, needed_status, timeout) with timeout>0 in case the needed_status condition is not meet the API block indefinitely. The same apply for nx_ip_status_check() API. The issue seems to come from the tx_mutex_get(&(ip_ptr -> nx_ip_protection), TX_WAIT_FOREVER); called within the above APIs.
To Reproduce eg. in case of wifi interface after having entered a wrong password the call to nx_ip_status_check(&IpInstance, NX_IP_INITIALIZE_DONE | NX_IP_LINK_ENABLED | NX_IP_INTERFACE_LINK_ENABLED, &actual_status, NX_IP_PERIODIC_RATE*5); will block undefinitely.
Expected behavior the nx_ip_status_check(), when called with timeout>0, should return if timeout expire