- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am using Murata SN8205, SDK V3.1.2.
Issue 1 -
We see that sometimes the device hangs on wiced_wifi_scan_networks(). The device can hang anytime and is very difficult to debug.
Is there any known issue between the communication between the STM32F2 MCU and the BCM43362?
The default interface is WWD SDIO, does the SDIO driver have any know issue? Is it advisable to use WWD SPI interface?
The device does not need high bandwidth transmission.
Issue 2 -
When we are in an environment with around 50-150 Access Point(AP), again we see that the wiced_wifi_scan_networks() hangs.
What is the expected behavior of WWD when encountering >100 Access points?
Is there any patch for these hang issues?
Regards,
Karthik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
hi,
I remember there is a patch to fix scan issue with more than 100 APs.
Maybe you can search the forum to find the patch.
Or you can test it with SDK-3.3.1.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Sam Lin,
Can you help direct to the mail thread?
Or can you tell the keyword to look for?
As we have been testing on SDK-3.1.2, it is too late to migrate. There is no official patch for SN8205 yet for the latest SDK.
Regards,
Karthik
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Is this using netx/threadx or freertos/LwIP?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Can you try 3.3.1 just to see if it solves the scan issue? It would be good to know. It may just be memory limitation.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Using NetX/ThreadX.
I will try, using the latest SDK-3.3.1.
The problem is that the issue is not very easy to simulate. If I run around 20 devices, then the issue may occur randomly on any device after a few days.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Agree that is difficult. That is a harsh environment. Are all 20 devices on the same channel? Eventually physics will take over. I will try to find out the max number in our test setup.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The 20 device are our custom PCB having the SN8205. They will regularly scan the surrounding APs. So no channel is fixed.
The Access Points do run in different channels. The reason of having so many access points is that we are in a square complex that is many stories high. Each corridor of the square complex has an access point which hosts 4 SSIDs each. So when we are in the center of the complex, the number of visible APs is a lot, even though the SSID name will overlap.
My main concern is the hang cannot recover. It would be ok if the watchdog can reboot on such condition.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Broadcom team,
We've also faced this same issue on top of WICED 3.3.1.
Just running command 'scan' at test app 'console' under environment with huge WiFi beacon flooding (you can simulate it via some hack tools).
Do you have patch or solution for this issue other than WICED 3.3.1?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Hardy,
Some questions on your environment. Are you seeing the hanging after a few days? How many APs did you simulate and which Broadcom board are you using? It'd be great if you could try it with our newest 3.4.0 SDK on the below link, let us know if you still see the same problem with it.
WICED SDK supporting Amazon Web Services 3.4.0-AWS
Thanks,
Jaeyoung
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jaeyoung,
Thanks!
We can easily reproduce this issue with using *hack* tools to simulate massive APs that's advertising beacon frame. Just commanding 'scan' less than couple times.
The board is our own custom board which is based on BCM943341WCD1.
We can try new SDK for double check later, now we will still focus on finding workaround or solution on top of 3.3.1.
- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The solution is to keep the application callback handler as lightweight as possible.
Another optimization that can be done is to extract only needed information from the driver in scan_result_handler().
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
callmekart wrote:
The solution is to keep the application callback handler as lightweight as possible.
Another optimization that can be done is to extract only needed information from the driver in scan_result_handler().
It should be fine to extract *all* information in scan_result_handler().
Othrewise, AFAICT it's a dangerous code.
Can you show the code that can cause hangup?
I'll try if I can reproduce with the same code.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
SCAN_BSSID_LIST_LENGTH is by default 100 so a max of 100 results would be returned
In general greater than this should not hang. But it is possible there is a corner case
You can try to change this value to a higher number and see if the hangs go away
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have tried manipulating SCAN_BSSID_LIST_LENGTH before, it did not help in my case.
I have tried to simulate the issue in lab unsuccessfully using mdk3 on Backtrack Linux.
The issue can only be seen in places with 150-200APs. And it is very hard to capture and reproduce.
I suspect the randomness in real world in terms of timing, ssid length, etc. may contribute to the issue.
I dont have access to the setup now, so I cannot debug further.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
nsankar wrote:
SCAN_BSSID_LIST_LENGTH is by default 100 so a max of 100 results would be returned
In general greater than this should not hang. But it is possible there is a corner case
You can try to change this value to a higher number and see if the hangs go away
I'm not convinced increasing SCAN_BSSID_LIST_LENGTH is a solution at all.
If you think there might be a problem in the corner case, figure out the
root cause rather than increase SCAN_BSSID_LIST_LENGTH.
IMHO, You should reduce SCAN_BSSID_LIST_LENGTH to a smaller value instead,
this makes it easier to check if the "corner case" is a issue or not.