hci_api_switch_to_tcu_mode() fails

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

We have a timeout for BLE advertising that will fire if the advertising callback does not get called within a certain window.  When this happens, we issue a hardware reset to the PAN1026, reset the SDK, and reinitialize everything.  This usually succeeds and allows us to proceed with our normal application.  However, I am now seeing a failure in hci_api_switch_to_tcu_mode().  Down in hci_api_tc35661_update_firmware(), one of the calls to hci_api_execute_m2_set() fails.

Digging down into the check_m2() function, the parse_hci_m2_xet_event() fails.  This function is failing due to the check on hci_api.c:158.  The event->event_code is 0x10, not the expected 0xff.  This happens consistently after repeated hardware resets of the PAN1026.  However, it happens for different instances in the loop that calls hci_api_execute_m2_set().  I've seen it for patches[] array items 5, 6 and 9.



6replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • The event->event_code is 0x10, not the expected 0xff

    Then this is a totally different HCI event message than expected.

    What are the other bytes in that message?

    Event code 0x10 is the event code for a hw error event.

    The next byte should be 0x01 - this is the command length.

    After that an error code is supplied.

    • 0x20 stands for maximum byte transmit interval exceeded
    • 0x21 stands for stop bit error
    • 0x22 stands for overwrite during RTS

    In the majority of cases customers see 0x22, which happens when PAN1026 indicates via RTS line that it cannot process data temporarily, but the host processors sends data regardlessly.

    If this is true for you as well, please check the RTS line at th time time the error occurs.

  • I think I found the issue - the startup code I was using didn't properly the RTS GPIO pin. I'll configure it correctly and report back if the issue comes up again.

  • Never mind my previous post, I am still seeing this issue.

    I was able to reproduce the issue.  Here is the full HCI event I received with the unexpected event_code:

    04 10 01 20

    So, it looks like I'm getting the maximum byte transmit interval exceeded error. I'm not sure what this means or what I need to do about it.

  • Does this have to do with the 5ms "maximum transmit interval between each byte" described in 4.1.3 of the PAN1026 application note (here)?

    Do I need to pace byte transmission by 5ms?  That is really slow.  I'm running at the slowest rate (115200 baud), but that results in byte times of 86.8us (@10bits/byte).  Or is this limit describing the time between UART packet transmissions (either HCI or TCU)?

  • It is the other way around. This limit describes the inter-byte spacing within a HCI packet.

    If the transmission of a HCI packet is started then all the following bytes for that packet may not be spaced more than 5ms apart.

    Any byte that is more than 5ms from the previous one will make the internal packet parser think that the byte is a new byte for the next packet.

    Each HCI packet has header information about the bytes to follow. If a packet is now short because of a bigger spacing inside the transmisson, PAN1026 will generate this error 0x20.

    Please check the UART transmission with a logic analyzer. When this problem happens, you should see this more than 5ms spacing within the transmission of the packet.

    I suggest that you review your implementation of uart_application_send_bytes().

    Is it interrupt-driven? Does it use a FIFO to buffer some bytes?

    For example, even if it is interrupt-driven, but does not have a FIFO, then some higher priority interrupt could block sending of bytes via UART and this problem could happen.

  • Ah, this makes more sense then.  It is very possible that we are having some sort of thread contention that is causing a delay in packet transmission.  We use FreeRTOS and the uart_appplication_send_bytes() does not use DMA, only blocking-mode transmission.  I will review our implementation to see if DMA, or at least interrupt-driven transmit, is feasible.

Like Follow
  • Status Answered
  • 2 yrs agoLast active
  • 6Replies
  • 185Views
  • 2 Following