- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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");
}
}
Solved! Go to Solution.
- Labels:
-
softAP
-
Wifi+Bluetooth
-
Wireless MCU
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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().
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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 );
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is still under review. I will let you know once I receive feedback internally.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This issue has been resolved in WICED SDK 6.1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.