4 Replies Latest reply on Oct 1, 2014 9:50 AM by grga

    After repeated 'Joins' device stops passing traffic

    wcurrier_1902616

      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?