cancel
Showing results for 
Search instead for 
Did you mean: 

WICED Studio Wi-Fi Combo

New Contributor II

The issue is observed fairly consistently with the code below on non-debug builds, but debug builds work well. It looks like wwd_management_set_event_handler() in wwd_wifi_stop_ap() is called too early (perhaps because wwd_wifi_sleep_flag semaphore wasn't cleared at some step before when initializing). wwd_wifi_start_ap() also fails with "Error: Soft AP or Wi-Fi Direct group owner already up" error after failed stopping.

I found a very similar issue here IOCTL times out during wwd_wifi_stop_ap()​ .

The board is BCM943362WCD4. SDK 5.1.0.

void application_start(void)

{

    wiced_init();

    wiced_ssid_t ssid;

    memset(&ssid, 0, sizeof(ssid));

    strncpy((char *) ssid.value, "11", 2);

    ssid.length = 2;

    wwd_result_t wwd_res = wwd_wifi_start_ap(&ssid, WICED_SECURITY_OPEN, NULL, 0,1);

    wiced_rtos_delay_milliseconds(1000);

    if (wwd_wifi_stop_ap())

    {

        printf("fail\n");

    }

    wwd_res = wwd_wifi_start_ap(&ssid, WICED_SECURITY_OPEN, NULL, 0,1);

    if (wwd_res)

    {

        printf("start fail\n");

    }

}

0 Likes
Reply
1 Solution
Moderator
Moderator

This issue has been resolved in WICED SDK 6.1.

View solution in original post

0 Likes
Reply
11 Replies
Moderator
Moderator

I have reproduced the issue in platform BCM943362WCD4 and raised a ticket internally to get this fixed. In the function definition of wwd_wifi_stop_ap(), when a 1ms delay is provided before wwd_management_set_event_handler( apsta_events, NULL, NULL, WWD_AP_INTERFACE  ), this issue is not seen. For the time being, run the project in debug mode when you are using wwd_wifi_stop_ap().

New Contributor II

Thanks. I dug a little bit deeper and found how to solve it in a reliable way:

at line 183 in WWD/internal/chips/43362/wwd_ap.c replace that:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

with this:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_AP_INTERFACE ) != WWD_SUCCESS )

It seems the problem affects almost all boards (excepting 4334x where WWD_AP_INTERFACE is already in place) but appears noticeably often only at some boards.

0 Likes
Reply
Honored Contributor

obolon_svitle wrote:

Thanks. I dug a little bit deeper and found how to solve it in a reliable way:

at line 183 in WWD/internal/chips/43362/wwd_ap.c replace that:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

with this:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_AP_INTERFACE ) != WWD_SUCCESS )

It seems the problem affects almost all boards (excepting 4334x where WWD_AP_INTERFACE is already in place) but appears noticeably often only at some boards.

Needs Cypress to confirm if this change is correct or not.

grsr​ can you confirm this?

I think it really needs code review:

WICED/WWD/internal/chips/4334x/wwd_ap.c:    if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_AP_INTERFACE ) != WWD_SUCCESS )

WICED/WWD/internal/chips/4334x/wwd_ap.c:    result = wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE );

WICED/WWD/internal/chips/43362/wwd_ap.c:    if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

WICED/WWD/internal/chips/43362/wwd_ap.c:    result = wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE );

WICED/WWD/internal/chips/4343x/wwd_ap.c:    if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

WICED/WWD/internal/chips/4343x/wwd_ap.c:    result = wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE );

WICED/WWD/internal/chips/4390x/wwd_ap.c:    if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

WICED/WWD/internal/chips/4390x/wwd_ap.c:    result = wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE );

0 Likes
Reply
Honored Contributor

axel.lin_1746341 wrote:

obolon_svitle wrote:

Thanks. I dug a little bit deeper and found how to solve it in a reliable way:

at line 183 in WWD/internal/chips/43362/wwd_ap.c replace that:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_STA_INTERFACE ) != WWD_SUCCESS )

with this:

if ( wwd_sdpcm_send_iovar( SDPCM_GET, buffer, &response, WWD_AP_INTERFACE ) != WWD_SUCCESS )

It seems the problem affects almost all boards (excepting 4334x where WWD_AP_INTERFACE is already in place) but appears noticeably often only at some boards.

Needs Cypress to confirm if this change is correct or not.

grsr can you confirm this?

Ping.

grsr​ Can you confirm if above change is correct or not?

0 Likes
Reply
Moderator
Moderator

This is still under review. I will let you know once I receive feedback internally.

0 Likes
Reply
Honored Contributor

grsr wrote:

This is still under review. I will let you know once I receive feedback internally.

If cypress can review and confirm the changes is correct,

then other users can pick up this fix directly rather than waiting for next release.

If a review for user provided fix takes such a long time, the review becomes pointless.

You are forcing users to *wait* for the fix.

0 Likes
Reply
Moderator
Moderator

The issue is caused due to a deadlock. When wwd_wifi_stop_ap() is called, the function wwd_management_set_event_handler() would be called and this function would acquire wwd_sdpcm_event_list_mutex. Later it would call wwd_sdpcm_send_iovar to send IOVAR and wait for response from WLAN firmware. However an ASYNC event is received which also waits on wwd_sdpcm_event_list_mutex already acquired. This causes a deadlock. The solution is to set the wwd_sdpcm_event_list_mutex before calling wwd_sdpcm_send_iovar(). I have attached a diff of wwd_sdpcm.c for the exact changes to be made.

0 Likes
Reply
Moderator
Moderator

This issue has been resolved in WICED SDK 6.1.

View solution in original post

0 Likes
Reply
Honored Contributor

Such 1ms delay is a classic dangerous code because it may work for one device but does not work for the other one.

If you think it works, it only hide bugs.

0 Likes
Reply
Honored Contributor

grsr wrote:

I have reproduced the issue in platform BCM943362WCD4 and raised a ticket internally to get this fixed. In the function

sdk-6.0.0 does not include this fix.

0 Likes
Reply
New Contributor II

Found yet another problem with incorrect AP initialization even if my previous fix was already in place.

If you add wiced_rtos_delay_milliseconds(3000); after wiced_init() to the code in the first message (delay may be different depending on *something*), then wwd_wifi_stop_ap() crashes when calling wwd_management_set_event_handler( apsta_events, NULL, NULL, WWD_AP_INTERFACE).

With "printf("evt %d %d %d\n",  event_header->interface, event_header->event_type, event_header->flags);" inside wwd_handle_apsta_event(), it looks like that WLC_E_LINK is received twice, whereas wwd_wifi_ap_up() waits for the semaphore only once.

Debug info with delay after wiced_init():

evt 1 54 0

evt 1 16 1

evt 1 16 1

without delay :

evt 1 54 0

evt 1 16 1

Observed at SDK 5.2, board CYW943907WAE3.