sl_Send() hangs after a few minutes (cc3100)

So far the only thing I found is adding a 100ms delay between the sends seems to remedy the problem (at least I haven't got hangs with it). Unfortunately this is more than my app can accept, and making the delay less brings back the hangs.

Any suggestions would be appreciated.

I have a similar problem. My device hangs sometimes at sl_RecvFrom
I'm using the device in non blocking mode and I send and receive data every 5s. About once an hour the MCU hangs in sl_RecvFrom.

Any idea?

Lacho is right. Normally I'm waiting 200ms between sl_sendTo and sl_RecvFrom. When I remove the delay it hangs quite often. But even with the delay it hangs about once per 2h.

I can do a watchdog reset in this cases, but its not a good solution.

Well I think I'm lost :) Tried many things to return outside of the loops, do timeouts, hacks, etc. on many places but no luck... 

TI, is this some known issue/limitation, can we expect a fix in some future SDK? Would it help if I try to setup some code that reproduces it on a tiva c (no custom hardware, just the launchpads stacked to each other) and paste it here?

Thanks!

Looks like this issue is going to get the same treatment like its brother from cc3000 - ie. total silence from TI.

Can you at least say if a fix may be coming or is not coming in the near future, so people who are blocked by this (like myself) start redesigning their products with alternatives?

Yes TI, please say if you plan to fix this bug or not.

The CC3100 driver hangs about once a hour. I have protocoled the hangs of the last 12h:

30.07.2014 20:25
30.07.2014 21:07
31.07.2014 00:26
31.07.2014 01:48   
31.07.2014 03:29   
31.07.2014 04:13   
31.07.2014 07:04   
31.07.2014 08:13

its quite easy to reproduce this bug. Just send a UDP packet to a Server and receive an answer (Non blocking mode) and let it a few hours running.

Folks,

Apologies for the delayed response.

We are trying to recreate the issue on our setup here - Please be assured that the problem will be investigated if the issue is hit.

Test is ongoing and I'llshare more details in some time.

-Praneet

To make it more similar to what you observing, can you share following details:

1. CC3100 or CC3200 

2. Revision of the Board 

3. TCP or UDP 

4. Running as Client or Server

5. Duration it takes to reproduce.

6. Any other information you have which may be helpful ?

Regards,
Geet

Dear Geet and Praneet

Thanks for the answer!  I'm using the following:

• My device: XCC3100HZ (Updated with Uniflash)
• UDP
• Running as Client
• It takes about 1-2 h until the device hangs

I'm doing the following:

Every 5s:

sl_sendTo

wait(200ms)

sl_recvFrom

I trying to create a simple example tomorrow with the BosterPacker where you can reproduce the bug.

Thanks for the reply, here is it from my side:

1. cc3100

2. rev 3.3, XCC3100HZ with latest sdk and service pack

3. tcp

4. running as client

5. reproduces every 1-2-3-5 minutes. But that's a few hundred or thousand sl_sends() for this time

sl_send gets called in a loop - like 10-20 times per second - the faster it gets called, the quicker it reproduces. The amount of data that gets sent doesn't seem to affect it. I do it with 1460 bytes, tried also with 512 - still happens.

In my case there's no sl_recv, just blind sending. Happens both in blocking and non-blocking mode.

Thanks!

Thanks for the infor Lacho.

The host platform you are using is TIVA C Connected ?? Is it reproducible with any other platform as well ?

Regards,

Geet

Dear David,

Thanks. Can you share the host MCU platform ?

Regards,

Geet

I'm currently using the ek-tm4c1294xl launchpad as a host. Haven't tried it with another mcu.

I did run it on the tm4c123 launchpad, but it was just the demo ping app, where it doesn't do so many quick sl_send()s

Hi Greet

We are using a MSP430G2955.

Regards

Lacho, David,

We've been trying to recreate the problem on our setup (CC3100-BP Rev3.3, v0.5.2-SDK and Tiva-C LP) but didn't hit the problem that you have mentioned.

While the tests are still running, we would need below additional infromation from you to take the issue, if any, to its resolution.

- Did you try recreating the issue w/ 'SinplLink Studio' as well? If not, can you please check this and confirm if the problem still persists?

- What's the access-point that you are using?

- If CC3100 is hosting the client, what's running as a server? Meaning, are you running an IPerf (or something similar) or is it a customized server? If it's a customized server, would it be possible to share the code w/ us?

- For the current failed tests, can you please share the wireshark and sniffer logs?

I suggest we get on to a short sync-up call - If you could please share your email-ID and location, I'll send out the call-bridge details.

Thanks & Regards,

Praneet

Hi Praneet,

I've been trying to reproduce that on a new project where just the problematic code is isolated and also without the additional hardware - just TI launchpads - if I manage to do it I'll send you the exact code.

So far I wasn't able to reproduce it with the code that I thought was problematic - sending lots of data to my server for a while. In my original setup it seemed pretty easy to reproduce, but looks like that's not the case and there's something hidden. So i'll need to run some more tests, but in the meantime I think I killed the cc3100 board, so I'm waiting for a replacement now.

I guess next week I should be ready with the tests and will be able to give more info.

Regards,

Lacho

So after spending a lot of time on this, it finally no longer hangs. The sl_send() seems to be fine, my biggest problem was that when I migrated the example code from tm4c123 to tm4c129 chips - I didn't do it properly.

More precisely the SysCtlClockGet function is not supported on tm4c129 - so my SPI clock and all bunch of other timings were wrong.

I also had some weird electrical spikes in the circuit, not sure how exactly and if they caused trouble...

But the API seems to be fine - now I don't have any hangings.

I faced a similar issue with cc3200.see Wireshark, first sl_recv() return length is wrong when server reassembled TCP segments(2 payloads). then sl_send()  fail. now I want to use watchdog, maybe save this project.