• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 40 subscribers
  • Views 528 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.

Sometimes hang in hci_event_handler

Jimmy Pedersen
Intellectual 430 points

Hi

Sometime I get a neverending loop in the hci_event_handler (in evnt_handler.c) while(1) loop. I've tracked it so far as that I can detect when it happens by adding debug output to your code.

hci_unsol_event_handler in evnt_handler.c:

    //handle a case where unsolicited event arrived, but was not handled by any of the cases above
    if ((event_type != tSLInformation.usRxEventOpcode) && (event_type != HCI_EVNT_PATCHES_REQ))
    {
    dprintf(0,"! Got unexpected unsolicited event:%d (Exp:%d) !\r\n",event_type,tSLInformation.usRxEventOpcode);
        return(1);
    }

I get this output just before it stops communicating on the WiFi:

! Got unexpected unsolicited event:4101 (Exp:0) !

sometimes it's 4100, but mostly 4101.

This happens sometimes when communicating actively and sometimes when there are no active connections.

I've just rechecked my code and made sure I got all the changes between 1.11 and 1.11.1 added to my code, and I can't find anything missing.

Any ideas?

Jimmy

  • 0
    TI__Expert 5295 points

    Hi Jimmy,

    Can you please describe the flow in more details?

    4100 - refers to recv event

    4101 - refers to accept event

    If you issue recv or accept commands, the application would be in blocking state waiting for this event. The following condition:

    if ((event_type != tSLInformation.usRxEventOpcode) && (event_type != HCI_EVNT_PATCHES_REQ))

    is to handle a situation where the application is waiting for a specific event, but during that time, an unsolicited event arrived, which was not handled by the other cases (above this condition). The function will treat it as "handled" by returning 1, which will in turn resume the spi. Without it, the spi would get stuck.

    I'd like to understand if you issue any of the accept/recv command, and what happens afterwards. To which event the application is waiting?

    Entering this if condition is a valid scenario, but should not cause the application to get stuck.

    Thanks,
    Tomer