server_state_info stuck in SER_COMMAND_BUSY

Module: PAN1026
SDK: 3.4.1 (w/ errata patch v1.0.0)

I occasionally get to a point in communications where the GATT server appears to be stuck in the SER_COMMAND_BUSY state.  Pausing the debugger after not sending any commands for a while, I see that the server_state_info[0] structure has the following values:

event_state = SER_EVENT_IDLE,
command_event_state = SER_COMMAND_BUSY,
notify_count = 0x00,
indication_state = SER_INDICATION_BUSY,
is_active = 0x01,
srv_characteristics = {...},
indication_characteristics = {...}

Is there a good way to reset these states?  Presently, any WRITE commands are rejected with the following error:

[WRN] ble_api_message_handler(): ble_api_message_handler() failed. Service id 0xd3c9
3replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • I suspect that for one of the previous GATT server commands the command_event_state is not properly reset.

    Maybe an error code path that is taken, where this handling is not properly implemented.

    Do you have further information about what you have been actually doing before the problem happened?

    Did you see any error message before the one you mentioned in your post?

    Did you disconnect and reconnect at some point?

    Of course a full dump of the TCU messages that are exchanged will help to pinpoint the problem.

    In any case I will forward this question to the Toshiba support team for further assistance.

  • Michael,

    Unfortunately, I have not been able to reliably reproduce the problem. Otherwise, I would provide a full TCU dump.  I'm not sure if I can produce the problem with the reduced performance speed while having the debug output print TCU data.

    Prior to this issue, I was running our client's Android app, testing communication over BLE.  There were many application-level commands issued, some while others were still being handled (they were ignored).  I do not recall disconnecting or reconnecting.

    I will try to duplicate the issue and post more data if possible.


  • I can understand that having the debug output turned out may result in different application behavior.

    The Toshiba support team is monitoring this issue, but they said that it is difficult to analyze, because they don't know what to look for exactly.

    I know it is a lot to ask for, but maybe the following is possible.

    If you have some memory to spare, then instead of writing the bytes to the debug  log directly, maybe you can write it to a simple ringbuffer only.

    Then, when the problem has happened, dump the ringbuffer to the debug console in one go. Then you can share it in this issue.

    Then it is possible to analyze the TCU messages and look for anomalies.

Like Follow
  • Status Answered
  • 2 yrs agoLast active
  • 3Replies
  • 245Views
  • 2 Following