Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
We are working with WICED version 2.4.1 and have encountered an intermittent problem where the radio stops passing traffic across both the STA or Soft AP interfaces.
Our upper-layer code frequently moves between SSIDs by calling ‘wiced_wifi_leave()’ (to disassociate from the ‘old’ access point) followed by ‘wiced_wifi_join()’ (to join a ‘new’ AP.) Occasionally, after several moves between SSIDs, the radio stops passing network traffic. The device never recovers and requires a re-boot to start working again.
Running the code in a debugger we have observed that the radio firmware has flowed off the transmit queue by sending a frame with the ‘wireless_flow_control’ flag in the header set to a non-zero value. This happens via a call to ‘wiced_bus_set_flow_control()’ in ‘wiced_process_bus_credit_update()’ (SDPCM.c) while processing an incoming frame. Any subsequent attempts by ‘wiced_send_one_packet()’ to fetch a buffer from the transmit queue fail when the call to ‘wiced_bus_is_flow_controlled()’ returns ‘true’. Our problem arises from the radio never flowing the transmit queue back on (by sending a frame with ‘wireless_flow_control’ set to zero.) Our debugging runs indicate that the radio firmware is functioning; the soft AP is still transmitting beacons and the radio is still receiving frames and passing them up to the WICED code (none with the flow control flag cleared.) Even after waiting several minutes the flow control flag is not being reset.
Could this be a bug in the radio firmware or are we doing something wrong?