• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 39 subscribers
  • Views 857 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.

recv api hangs erratically

Keegan Hernandez1
Prodigy 65 points

Hello,

I have ported the host driver to use SPI on the LPC1343 cortex-m3 processor. For the most part, everything seems to be working. I can connect to networks, set up server, accept clients, and send data.

However, sometimes when trying to receive (using recv) the CC3000 seems to hang, causing my host code to hang in a while loop: (amount of time until this happens varies) 

unsigned char *
hci_event_handler(void *pRetParams, unsigned char *from, unsigned char *fromlen)
{

...

while (1)
{
if (tSLInformation.usEventOrDataReceived != 0)

...

many others seem to have had problems at this location.

I have viewed the CS and IRQ lines on the oscilloscope. Every IRQ is at least being serviced because I can see the CS line asserted for each IRQ assertion. Right before the hanging event, there is one final read operation, and then the IRQ line remains high permanently, and recv function hangs.

Any ideas on how to solve this issue? Since HCI is undocumented, I can't think of a way to pinpoint the issue.

EDIT: I have discovered it is not entirely related to "recv." Even if I don't attempt to receive data, if the client sends data to the CC3000 server over TCP, the CC3000 and host will tend to hang during some API call, even "send" for example.

But this problem doesn't happen if the client doesn't send data to the CC3000 server.

  • 0
    TI__Mastermind 27095 points

    Hi Keegan,

    Are you using the latest Host v1.11.1 and Service pack of 1.24? It looks like some issue with the flow control. Just to confirm, can you please provide us the debug logs following the below link?

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

    Before you get this log, please call the API in your code. netapp_set_debug_level(0x3ff);

    Also, can you please let me know if adding some delay between each recv/send is giving you a different result?

    Thanks & Regards,

    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Prodigy 65 points

    Hi There. I'm using the latest host driver and CC3000 reports back version 1.24. Adding various delays is one of the methods I've used to try and pinpoint the problem, but no luck

    For the particular logs that I attached this is what happens:

    1. Initialization
    2. scans nearby networks
    3. connects to AP "MacBook"
    4. sets up server socket
    5. accepts client
    6. sends 1000 bytes to a client in a loop every 500ms

    I didn't use "recv" at all for this test, but if the client sends data to the CC3000 server, the host eventually hangs at some API call, which is where I stop the log (although the CC3000 does keep logging after the host driver hangs, but the IRQ line never goes low)

    Thanks for your help!

  • 0 in reply to Keegan Hernandez1
    Prodigy 65 points

    Other log.

    Is there a way to interpret these logs myself for future reference?

  • 0 in reply to Keegan Hernandez1
    TI__Mastermind 27095 points

    Hi Keegan,

    Thanks for the logs. I will look into the logs and get back to you.

    Thanks & Regards,

    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Prodigy 65 points

    Hi Raghavendra,

    I will save you some time and say I am pretty sure I got the problem fixed. It seems it was actually a problem with my SPI driver, which just didn't show up until now.

    On the wiki for host driver porting, there is this line:

    • SpiResumeSpi – Resumes SPI communication under the assumption that it was previously paused within the SPI driver itself.

    I implemented this function, but this didn't really make sense to me ("under the assumption that it was previous paused?") because the wiki does not say that the IRQ needs to be disabled before calling the simple link receive handler. Or else the SPI code will keep handling read requests from the SPI driver and the previous request won't be handled by the simple link code.

    I finally noticed the line to disable the interrupt during read operation in the downloadable example drivers, it isn't shown in the code snippet on the wiki.

    One other thing I noticed was that I have to call recv pretty soon after the client sends data to the server, or some kind of connection error happens and I can no longer send. Is this normal behavior for sockets?

    Thanks,
    Keegan

  • 0 in reply to Keegan Hernandez1
    Prodigy 65 points

    I take it back. The fix I made delays the problem (api calls hanging), but it still happens after a few minutes of continuous data transfer. Working on new logs now.

    Again, thanks for your help and attention.

    - Keegan

  • 0 in reply to Keegan Hernandez1
    TI__Mastermind 27095 points

    Hi Keegan,

    In the previous logs, I could not see much. Did you check if all the interrupts from CC3000 is handled in the Host Driver?

    Also, when you are capturing the logs, please make sure you add a call o API 'netapp_set_debug_level' after  every call to wlan_start().

    Thanks & Regards,

    Raghavendra

  • 0 in reply to Raghavendra Shenoy
    Prodigy 65 points

    Hello,

    It turned out the latest problem was unrelated to both the simple link host driver and the CC3000.

    However, the original API hanging problem was indeed caused by improperly implemented SPI layer (even though it worked most of the time). It was solved by making sure interrupts are manually disabled before calling the simple link RX handler. When the simple link driver finishes handling the read result, it will automatically invoke the Spi Resume callback, in which the interrupt should be re-enabled, and the next read operation can continue.

    Otherwise, many unsolicited read operations may occur before the previous is handled, causing the host to fritz/hang.

    Perhaps, someone at TI could mention that this definitely needs clarified in the host porting wiki page, because it is definitely doesn't seem to be mentioned, or maybe it seems obvious only to people who better understand the driver.

    Thanks for looking into the problem for me,

    Keegan