• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 41 subscribers
  • Views 1392 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Simplelink driver hangs in sl_RecvFrom

David Eberli
Intellectual 595 points
Other Parts Discussed in Thread: CC3100, MSP430G2955

Hi

I'm using the CC3100 in non-blocking mode. Rarely the simplelink driver hangs in the sl_RecvFrom Method. It's quite hard to reproduce. My devices hangs about once all 4h. (Hangs once per ~2880 calls).

I think the problem is that the UDP Packet was not received correctly. This is not a problem, but the device should not hang forever in the sl_RecvFrom Method.

Call stack:

In the   _SlDrvRxHdrRead(_u8 *pBuf, _u8 *pAlignSize) Method the driver getting stuck at this line:

/*  3. Debug limit of scan */
VERIFY_PROTOCOL(SyncCnt < SL_SYNC_SCAN_THRESHOLD);

SyncCnt: 2000

So, what does SyncCnt means? How can I avoid that all my devices getting stuck? What are the consequences when I comment this line out?

Thanks

David

  • 0
    Intellectual 595 points

    TI, do you have any workaround for this?

    I'm sure sooner or later everybody using UDP will run into this problem.

  • 0 in reply to David Eberli
    TI__Genius 16370 points

    David,

    The protocol (for host <--> device communication) uses 32b synchronization words to keep the host and device in sync - In your case, it seems that the host has either missed or not able to identify this sync-pattern from the device, and hence a protocol error.

    Which host-platform are you using w/ CC3100? Were you are to reproduce the issue w/ 'Simplelink-Studio? 

    -Praneet 

  • 0 in reply to Praneet Kumar
    Intellectual 595 points

    Hi Praneet

    I'm using a MSP430G2955 host. No, I don't use the Simplelink Studio. I'm using the Code Composer Studio (Eclipse).

    This protocol error happens on every device we have. But it's quite hard to reproduce (~ once in 4h).

    It happens with the XCC3100HZ (Booster Pack) and the CC3100R1 devices. We are using the last SDK (1.0) and the last service pack (1.0.0.1.0).

    A bug fix or a workaround would be great.

    Thanks,

    David

  • 0 in reply to David Eberli
    TI__Genius 16370 points

    David,

    Did you try the same test by putting the networking subsystem in 'ALWAYS-ON' as requested by us over an email? It would be great if you could share the logic-analyzer captures of the failure. In this capture I would like to see the status of the IRQ line and the MOSI/MISO from the point the last IRQ is raised.

    -Praneet

  • 0 in reply to Praneet Kumar
    Expert 2460 points

    i'm experiencing similar issues with sl_Recv(), using it in a polling mode every 100ms

    looking at the logic analyzer, the "normal" case show the host initially writing 12 bytes; this is then follow with an up-down pulse on the IRQ line, after which 24 bytes are exchanged....   note that this is a typical "poll" when there is actually no data present; in fact, no data is being sent to my target device in this experiment....

    within 10-20 cycles of polling, things get "stuck" in that the initial 12 bytes are transmitted and the IRQ line goes high; but for some reason the IRQ does not go low again!!!!!   and no attempt appears to be made to read the subsequent bytes from the CC3100....

    at this time, i know that i've received the IRQ interrupt (i'm triggering on the rising edge fortunately); i suppose i could work my way through the host driver code, looking for some sort of spin-loop that is getting stuck....

    any insights would be helpful here....

    thanks, bob.

  • 0 in reply to bob frankel
    Intellectual 595 points

    Hi Bob

    Do you have already found a workaround? Or is there any news from TI?


    Regards,

    David

  • 0 in reply to David Eberli
    Expert 2460 points

    nothing on my end....   but see some information found here:  http://e2e.ti.com/support/wireless_connectivity/f/968/t/387269.aspx

    i am seeing a glitch on the IRQ line in the middle of a recv cycle, which is unexpected from the view of the TI driver code....  all attempts at ignoring the spurious interrupt have failed; the CC3100 is in funky state at that point....