- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
After some time module (in AP mode) becomes unresponsive for a few seconds. After that it again starts processing requests.
For example:
Reply from 192.168.0.1: bytes=100 time=3ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=8ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=1ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=1ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=3ms TTL=128
Request timed out.
Request timed out.
Reply from 192.168.0.1: bytes=100 time=1725ms TTL=128
Reply from 192.168.0.1: bytes=100 time=3ms TTL=128
Reply from 192.168.0.1: bytes=100 time=3ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=10ms TTL=128
Reply from 192.168.0.1: bytes=100 time=12ms TTL=128
Reply from 192.168.0.1: bytes=100 time=1ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=3ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Reply from 192.168.0.1: bytes=100 time=1ms TTL=128
Reply from 192.168.0.1: bytes=100 time=4ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Request timed out.
Request timed out.
Reply from 192.168.0.1: bytes=100 time=1352ms TTL=128
Reply from 192.168.0.1: bytes=100 time=11ms TTL=128
Reply from 192.168.0.1: bytes=100 time=2ms TTL=128
Does anyone have a clue what is going on? Thank you and kind regards, Matej
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your system may temporarily run of packet buffers due to the large ICMP packet size; hence the ping timeout. The default RX packet pool size is 7 packets. When a 6KB ping request is received, ~4 packets are used, which leaves the system with 3 RX packets for everything else including scanning and webserver for the config mode. You can try increasing RX_PACKET_POOL_SIZE to a larger number and see if the timeout goes away.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Matej
I tried it and it worked properly.
Could you tell me detail of yours?
Below are my test environment.
Board: BCM943362WCD4_EVB
SDK: 2.4.0
Application: test.console
Regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Initial problem is that module config page is not loading reliably. Device Settings page is usually loaded and then it hangs on loading WiFi Settings page (especially images). If not on the first try it definitely stops working on page refresh. From this I tried pinging the module and the same behavior repeats.
My environment is as follows:
Board: SN8200EVAL1
SDK: 2.4.0
Application: snip.config_mode
snip.config_mode-SN8200x download run JTAG=SN8200EVAL1
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
snip.config_mode works properly too.
I can reload WiFi setting page including images several times.
And pinging also doesn't time out.
Have you tried with other board?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sure, we have tried running this app on two SN8200 EVK+ boards. On both we are experiencing the same behavior. You think that this issue is related to the SN8200?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had similar issues on SN8200+EVK which went away after the second bank of Flash is properly flashed. I tried snip.config_mode and it is working fine on my board. The Wiced Flash tool enables only the first bank of Flash for STM32F1xx family, when the binary image of app +DCT+bootloader spills over 512k, they are not programmed properly into the flash. SN8200 EVK+ has more Flash memory but needs proper flashed. Please contact Murata-WS to get an updated patch.
BR,
Xinsi Lin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mat,
Xinsi is a software engineer with the Murata team in Dallas, TX.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mat,
I think a new patch(TG_WICED240_DMG_BASELINE_02262014) is avaiblabe on MurataKnowledgeTree.
Please post here if you have any issue or question.
Br,
Xinsi Lin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Xinsi and Paul,
I have re-installed WICED SDK and applied TG_WICED240_DMG_BASELINE_11152013 and TG_WICED240_DMG_BASELINE_02262014 patch. Unfortunately, the problem still remains. Basically new patch did not change anything in my workspace because I have been using OpenOCD config from Murata SNIC application.
Web page eventually stop working (also ping) while WiFi connection seems to be ok because I can disconnect and connect the module AP.
Best regards,
Matej
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mat,
I don't know how your setup looks like, do you use Broadcom IDE + Murata's OpenOCD configs (SNIC-8200-03-37191) ?
Murata's OpenOCD configs (SNIC-8200-03-37191) is intended for using with Murata's SNIC monitor NOT to mix with Broadcom IDE.
Is it possible for you to take out Murata OpenOCD configs? and build with
snip.config_mode-SN8200x download run
If not, please get a branch new SDK 2.4.0 and apply the two patches and build with snip.config_mode-SN8200x download run.
Br,
Xinsi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Previously, I have been using WICED IDE + Murata's OpenOCD configs (SNIC-8200-03-37191). Today I have re-installed WICED SDK and applied patches to the fresh workspace, as you suggest.
I investigated this problem a little bit more. After few page changes between Device Settings and WiFi Settings (and/or pinging) the images starts to load slow (approx 15 sec) until even page cannot be loaded and lastly the whole module hangs. Now I need to take back last claim in previous post, since module AP becomes inaccessible.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mat,
We will to repeat what you did. Meanwhile can you please try if you can run snip.scan smoothly on your setup, want to see if you also have problem with other applications, which may be an indication of something still not right in configuartion.
Thanks,
Xinsi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
can you please try ping Ap without change pages? want to know if ping itself is working fine.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The pinging works until the packet size is under 5910 bytes. If the packet is bigger than this it starts to timeout. If I open a web page while pinging it immediately time outs.
I did not have any problems with applications without web server. I will try spin.scan asap and report back.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Xinsi, did you managed to replicate the issue?
how fix issue "web scan make web block"this issue is likely to be related.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Mat,
I am running snip.scan application for long time, thus I believe the updated SN8200 patch has taken care of the flash bank config issue. Before applying the patch, the snip.scan was seen intermittant locking.
Regarding the issue you reported, I tried connecting to the Config AP and changing pages while pinging from a PC. I haven't seen the issue. I am using IE from PC. What do you use?
BTW, we are contacting Broadcom to ask if they are aware of any issue on their WCD2 platform which is also using STM32F1xx.
Thanks,
Xinsi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you try ping it with 6000 bytes? Try this: ping 192.168.0.1 -l 6000
Could be that our PCs send some large packets to the module and than the module hangs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Your system may temporarily run of packet buffers due to the large ICMP packet size; hence the ping timeout. The default RX packet pool size is 7 packets. When a 6KB ping request is received, ~4 packets are used, which leaves the system with 3 RX packets for everything else including scanning and webserver for the config mode. You can try increasing RX_PACKET_POOL_SIZE to a larger number and see if the timeout goes away.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks gerdiman, you are right, packet pool size is the source of the problem. We are using Murata SN8200 that is based on STM32F1. Due to smaller RAM on STM32F1, the default packet size is reduced to only 4 packets.
STM32F10x does not have enough RAM space. Reduce and overwrite the network packet pool size
GLOBAL_DEFINES += TX_PACKET_POOL_SIZE=4
GLOBAL_DEFINES += RX_PACKET_POOL_SIZE=4
With packet pool size set to 7, configuration web page started to work normally. =D
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sweet!