CC3100: sl_Recv never returns

I should also add that the MAC sniffing application is essentially the same as the transceiver mode example that comes with SimpleLink SDK 1.2.0.

Hi Doug,

Are you using the latest versions of the CC3100 SDK and service pack? https://www.ti.com/tool/download/CC3200SDK 

Where exactly in the driver do you see the application getting stuck?

You see this happening on some devices, but not all of them--correct?

Best regards,

Jesse

Thanks for your reply Jesse. I was able to find the problem to sl_Recv getting stuck, there's a bug in the driver but it looks like it was fixed in 1.3.0 and I was also able to patch my local version based on 1.2.0 to get around the timing issue, however, when I fix it I now get an error thrown by the driver when I run "sl_Start", the error is that the sync operation timed out and this is on all devices whether they were previously working or not. I should mention that I'm debugging an application that's 5 years old and has just recently encountered these problems and that the person who wrote the code no longer works here. It seems like the problem must be timing-related but again I'm really surprised because it's been copied from the transceiver mode example... 

Your link is for the CC3200 SDK, is it compatible and meant to be used on the CC3100?

Any suggestions for why the "sl_Start" function would encounter a timeout error?

Thanks,
Doug Burrell

Hey Doug,

My mistake, I meant to link to the CC3100 SDK and service packs (https://www.ti.com/tool/CC3100SDK). Are you using the latest service pack as well?

Can you provide the specific error code sl_Start is returning?

Best regards,

Jesse

Hi Jesse, the error code is SL_DEVICE_DRIVER_TIMEOUT_ASYNC_EVENT. It's thrown in "_SlDrvSyncObjWaitTimeout" which is called from line 146 of device.c in the simplelink source folder.

No, still running an older service pack as far as I know.

Thanks,
Doug Burrell

Hi Doug,

Thanks for the additional info.

1. You can check the service pack using the steps described here (https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/976711/cc3100mod-sl_devget-does-not-get-the-info-correctly-after-the-servciepack-is-updated), but please flash the latest service pack to the CC3100.
2. What did you change in the driver to patch your SDK 1.2 version? Can you fully update to SDK v1.3?
3. What are you using for your host MCU?
4. You mentioned your application is based on the transceiver mode example. Can you test your board with a known working example such as transceiver_mode?

Best regards,

Jesse

Hi Jesse,

Thanks for the extra suggestions. I confirmed we're using service pack 1.0.1.6-2.7.0.0. I've attempted to upgrade to a newer one however the code is already close to the limit of the flash on the MCU so there's not enough room for the next service pack since it's larger than the current.

In the current SDK 1.2.0 I changed "NONOS_WAIT_FOREVER" to 0xFFFFFF, it was previously 0xFF but this was causing any timeouts greater than 0xFF to be treated as a wait forever. The odd part is that when I made this change the working boards stopped working. There must be some timed loops that actually require a longer wait time.

We're using an MSP430F5529.

I'll have a look to compare the transceiver mode example code to ours and see if there are any obvious differences. Our product also has capabilities for connecting to WiFi access points and that functionality still works, even on boards that can't do the MAC sniffing.

As I said, our code and hardware haven't changed in 5 years but just recently we're getting these failures. The parts we're getting from TI are new but they're still CC3100 R1 chips so that shouldn't be an issue. Have you heard of any "bad" CC3100 chips from customers?

Thanks,
Doug