Wifi module hangs.

Terje Nikolaisen

I have a LS research module with latest release 1.10.1. When connecting to an access point, and sending mDNS packets each second, the module hangs after about 1 minute. This happens on my own design, and on the demo board CC3000 + MSP430 FRAM. I've also tried the FRAM Sensor app and the Basic Wifi App with 0b command on the demo board. Both will crash in about a minute. I've tested with both TP-link and a 3COM router. Also with different firmware on the TP-Link. No encryption is used on the wifi link.

It should be noted that we have about 10 computers with windows on the network, NAS server and Linux servers running on the same network. When testing this morning, I removed some connections from the main switch, and that helped. The chrashes were fewer after disconnecting about 3 computers. The demo board works fine at home connected to an ASUS router.

I've been trying to trace with Wireshark, but I cannot find any malformed packets or any consistency to the crash. The IRQ line from the Wifi module will remain high after sending the mDNS command, and i will get a timeout due to this on my design in the event handler routine.. Only way to get in contact with the wifi module is to do a reset and power on the module again.

Any ideas?

over 12 years ago

0 Dotan Ziv over 12 years ago

TI__Expert 5840 points

Hi,

Can you please share log file as described on the following link?

http://processors.wiki.ti.com/index.php/CC3000_Logger

The Log is in binary, once you share it, we will be able to analyze what goes wrong.

Regards,

Dotan

0 Dmitry Bodnya over 12 years ago in reply to Dotan Ziv

Expert 1140 points

Hi.

Sometimes in different situations, CC3000 hangs too in my application. I'd like to read log too.

I read all info on the link you posted and I don't understand what pin is called NS_UART_DBG? I didn't find such name in CC3000 documentation.

Thank you.

0 Terje Nikolaisen over 12 years ago in reply to Dotan Ziv

Prodigy 185 points

Here's the Log file from pin 1 on J4 of the demo board. I couldn't find any data on pin 2, so if you need log from other pins, please advice which pins to use.

Followed instructions in http://e2e.ti.com/support/low_power_rf/f/851/t/251957.aspx

The log is from start connecting to AP, and then sending some 0b commands. It hung at the end, but I could still see data coming from the logger after the Basic Wifi App became unresponsive.

0 Dmitry Bodnya over 12 years ago in reply to Terje Nikolaisen

Expert 1140 points

I see some UART activity on pin 1 of J4 and pin 3 of J4.

On pin 2 is only 1.8V I see.

Is Pin 1 and Pin 3 a required? for both logs reading?

0 Dmitry Bodnya over 12 years ago in reply to Dmitry Bodnya

Expert 1140 points

I found description of NS_UART_DBG and WL_UART_DBG.

These pins are mentioned in CC3000MOD schematic ( http://www.ti.com/litv/pdf/swru326 ).

And on LSR TIWI-SL EM BOARD these pins are NS_UARTD - pin 1 on J4 and WL_UARTD - pin 3 on J4.

Will try to read log from these pins..

0 Shlomi Itzhak over 12 years ago in reply to Dmitry Bodnya

TI__Guru 64445 points

yes, for LSR it is pins J4-1 and J4-3 as you mentioned.

I doubled checked it locally.

Shlomi

0 Terje Nikolaisen over 12 years ago in reply to Dotan Ziv

Prodigy 185 points

Here's the log for pin 3 on J4.

After crash, it will not issue any more data on this pin. The log for pin 1 can be found in my previous post.

Terje

0 Terje Nikolaisen over 12 years ago in reply to Dotan Ziv

Prodigy 185 points

I don't know if the last log was correct. Tera Term seems to do something strange if not reset after a while...

Anyway here's another log for pin3 J4.

Terje

0 Dmitry Bodnya over 12 years ago in reply to Shlomi Itzhak

Expert 1140 points

Hi.

I don't know if I should open a new thread.

Here is log of my "cc3000 hangs" situation.

8322.ns_uartd.dat

My program activity is:

1) Connect to WPA2 encrypted network.

2) Open UDP Receive socket and UDP Send socket(independent because of bug: after first send though socket, I can't receive thruogh it).

3) Poll socket about received packets. If receive something, send big packet back(1400b) to the source port.

4) Periodically check if I still sonnected to the network.

After some time CC3000 stops responding.

I am using Patch version 1.8, because 1.10.1 have bug(again) - recvfrom returns with wrong "from" information, I don't know who sent me a packet.

This bug was fixed in 1.8 but appears in 1.10.1 again.

Hope you can see something in these logs.

0 Dmitry Bodnya over 12 years ago in reply to Dmitry Bodnya

Expert 1140 points

7268.wl_uartd.dat

Second log is here

0 Shlomi Itzhak over 12 years ago in reply to Dmitry Bodnya

TI__Guru 64445 points

I apologize for the response time but I'm OOO.

Regarding the FW/DRV logs, I'm able to open and decode only the last FW log, 7268.wl_uartd.

All the rest are somehow corrupted and without the DRV logs it is hard to know what is wrong.

Btw, a new release has been uploaded to WiKi (the send after receive is fixed). It can be found here: http://processors.wiki.ti.com/index.php/CC3000_Wi-Fi_Downloads.

0 Terje Nikolaisen over 12 years ago in reply to Shlomi Itzhak

Prodigy 185 points

I can see that mDNS bug was fixed on release 1.10.02

I've tried the 1.10.2 version on the FRAM board now, and it seems to accept the mDNS packets. It does not crash anymore. However, after 5-10 minutes The packets will no longer be transmitted. I send the 0b command every second, and wireshark shows them correctly, but then it stops receiving. After resetting the FRAM board, they show up again. I can transmit UDP packets by 04 command after the mDNS fails.

I need to try this on my own design, but I wont be able to do this because of easter break. Also the logs will have to wait until I'm back at work.

Terje

0 Shlomi Itzhak over 12 years ago in reply to Terje Nikolaisen

TI__Guru 64445 points

Thanks Terje,

I'm glad to know you see improvement with the new release.

Please share the logs when you can.

Shlomi

0 ManishK over 12 years ago in reply to Shlomi Itzhak

Intellectual 560 points

Hi Shlomi,

Are you talking about TiWi - SL EM board from LSR (http://www.lsr.com/downloads/products/330-0086.pdf ) ?

If so, here is the response I got from one of the LSR employee about data logger debug pins (http://processors.wiki.ti.com/index.php/CC3000_Logger )

"Pin 2 and 6 on the module are UART debug lines (TX only). These lines are 1.8V and can be used with special TI debugging software on the PC. These lines are used to see what the CC3000 cores are doing. Pin 6 (NS_UARTD) is debug for the networking stack in the CC3000 and Pin 2 (WL_UART_DBG) is debug for the WLAN RF core.

All of these pins are available on J4 of the EM board."

Please confirm

Thanks,

Manish K

0 Shlomi Itzhak over 12 years ago in reply to ManishK

TI__Guru 64445 points

LSR denotes pin 2 and 6 on the module corresponds to WL_UART_DBG and NS_UARTD respectively. I believe this is OK. I was referring to the pins on connector J4. On J4, pin 1 and pin 3 denote WL_UART_DBG and NS_UARTD respectively.

0 ManishK over 12 years ago in reply to Shlomi Itzhak

Intellectual 560 points

Hi Shlomi,

Thanks for reply.

I was also refering to pin 2 and 6 of J4 (of LSR EM board). And I think these pins have same number on module as well.

Are you reffering to CC3000 EM boards and same pins are on J4-1 and J4-3 (of CC3000 EM baord).

Sorry, if it creates confusion. I just need to clearly understand this since we are making a custome board and need these pins out for debugging.

Please let me know what you think.

Thanks,

Manish K

0 Shlomi Itzhak over 12 years ago in reply to ManishK

TI__Guru 64445 points

from the table above it really looks like J4-2 and J4-6 pins are the two pins for driver and firmware logs.

BUT, from my experience, I am working with J4-1 and J4-3 pins for log captures.

Maybe it depends on the EM board revision.

I cannot test it until I come back from holiday but if this is what LSR is indicating, then I guess this is the case.

0 ManishK over 12 years ago in reply to Shlomi Itzhak

Intellectual 560 points

Hi Shlomi,

Please confirm from your end so that it would be clear to everyone.

Thanks in advance.

Manish Kakra

0 Terje Nikolaisen over 12 years ago in reply to Shlomi Itzhak

Prodigy 185 points

Upgraded to v1.10.2

There's still a bug with the mDNS. The module will respond now after sending lots of mDNS packets, so the IRQ seems to be ok.

I've tested on the demo board and my own design.

But within 1 minute, the packets are no longer transmitted. Wireshark shows maybe 20-40 packets when sending with 1 sec interval. Then it stops.

Seems like udp sending by 03 and 04 command works afterwards on the demo board, but I cannot connect to TCP server on my design afterwards.

On my design, I create a TCP listen socket on port 80, and then send mDNS packets.

I will share the logs when I have assembled a high speed level converter... The other one didn't cope with 921600 baud...

Terje

0 Terje Nikolaisen over 12 years ago in reply to Dotan Ziv

Prodigy 185 points

I have created some logs with a new hi speed logger now.

One with log from reset, and one with log from start sending 02 command.

Please se if these are ok. My scope shows the RS232 waveforms to be ok.

Terje

0 Terje Nikolaisen over 12 years ago in reply to Terje Nikolaisen

Prodigy 185 points

Log1

0 Terje Nikolaisen over 12 years ago in reply to Terje Nikolaisen

Prodigy 185 points

Log 1

0 Terje Nikolaisen over 12 years ago in reply to Terje Nikolaisen

Prodigy 185 points

Log 2

0 Terje Nikolaisen over 12 years ago in reply to Terje Nikolaisen

Prodigy 185 points

Log 2. Damn, I can't upload more than 1 file at a time...

0 Shlomi Itzhak over 12 years ago in reply to Terje Nikolaisen

TI__Guru 64445 points

Terje,

I have looked at the logs (some of them are not complete but enough for me to conclude) and it seems as the RX path on CC3000 is getting stuck.

The root casue is the mDNS indeed and it is already fixed but should be released in the coming release (due to end of April).

BR,

Shlomi

Wi-Fi

Wi-Fi forum

Wifi module hangs.