Module is unresponsive

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

cross mob
mahe_2162211
Level 3
Level 3
First like received First like given

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

0 Likes
1 Solution
Anonymous
Not applicable

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.

View solution in original post

19 Replies
Anonymous
Not applicable

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,

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

0 Likes
Anonymous
Not applicable

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?

0 Likes

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?

0 Likes
Anonymous
Not applicable

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

0 Likes
Anonymous
Not applicable

Hi Mat,

Xinsi is a software engineer with the Murata team in Dallas, TX. 

0 Likes
Anonymous
Not applicable

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

0 Likes

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

0 Likes
Anonymous
Not applicable


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

0 Likes

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.

0 Likes
Anonymous
Not applicable


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

0 Likes
Anonymous
Not applicable


can you please try ping Ap without change pages? want to know if ping itself is working fine. 

0 Likes

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.

0 Likes

Xinsi, did you managed to replicate the issue?

how fix issue "web scan make web block"this issue is likely to be related.

0 Likes
Anonymous
Not applicable

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

0 Likes

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.

0 Likes
Anonymous
Not applicable

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.

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.

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

0 Likes
Anonymous
Not applicable

Sweet!

0 Likes