wwd_wifi_stop_ap fails with error 2

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
AnCh_2110841
Level 1
Level 1
First like received First like given

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
1 Solution

This issue has been resolved in WICED SDK 6.1.

View solution in original post

0 Likes
11 Replies
GauravS_31
Moderator
Moderator
Moderator
10 questions asked 250 solutions authored 250 sign-ins

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().

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

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

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

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

0 Likes

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
lock attach
Attachments are accessible only for community members.

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

This issue has been resolved in WICED SDK 6.1.

0 Likes

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

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
AnCh_2110841
Level 1
Level 1
First like received First like given

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.