CC256x init script not applied to chipset during initialization

[Robin-Velas]

Environment
i.MX6 (VAR-SOM-SOLO) with WL18MODGI using SafeRTOS (FreeRTOS similar). BTstack version : 1.6.2.

Issue:
When using BTstack with a WL18MODGI (CC256x-compatible) module, the init script set via btstack_chipset_cc256x_set_init_script() is silently ignored during HCI initialization.

Expected Behavior :
After calling:

btstack_chipset_cc256x_set_init_script(&cc256x_init_script, cc256x_init_script_size);
hci_set_chipset(btstack_chipset_cc256x_instance());
btstack_main(0, NULL);
btstack_run_loop_execute();

BTstack should, at one point, use chipset_next_command(..) to send chipset firmware datas

Observed behavior:
HCI Reset is correctly sent and acknowledged
Standard HCI commands continue
Vendor-specific CC256x commands are never sent
Chipset remains unconfigured with default firmware

Serial HCI Log

[00:00:02.451] LOG -- btstack_run_loop_safertos.c.228: run loop init, task 0x100295b0, queue item size 8
[00:00:02.482] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:00:02.497] LOG -- hci.c.5546: hci_power_control: 1, current mode 0
[00:00:02.504] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:00:02.621] LOG -- hci.c.8159: BTSTACK_EVENT_STATE 1
[00:00:02.623] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:02.630] CMD => 03 0C 00
[00:00:02.655] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:02.662] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 169
[00:00:02.669] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 162
[00:00:02.837] LOG -- hci.c.1814: Resend HCI Reset
[00:00:02.839] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:02.846] CMD => 03 0C 00
[00:00:02.848] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 210
[00:00:02.855] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:02.862] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 185
[00:00:03.054] LOG -- hci.c.1814: Resend HCI Reset
[00:00:03.056] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:03.063] CMD => 03 0C 00
[00:00:03.065] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 209
[00:00:03.072] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:03.079] EVT <= 0E 04 01 03 0C 00
[00:00:03.083] LOG -- hci.c.2408: Command complete for expected opcode 0c03 at substate 1
[00:00:03.090] LOG -- hci.c.1873: hci_initializing_run: substate 2, can send 1
[00:00:03.097] CMD => 01 10 00
[00:03:47.861] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 4294967295
[00:03:47.868] LOG -- hci.c.1873: hci_initializing_run: substate 3, can send 0
[00:03:48.898] LOG -- btstack_run_loop_safertos.c.197: RL: wait with timeout 4294967295

Is there a strict call order between hci_set_chipset() and other BTstack init calls?
Any known quirks with WL18MODGI compared to CC256x?
Is there something specific to do to trigger the pre initialization?

Best regards

[mringwal]

Hi @Robin-Velas.

Did you create the SafeRTOS version? Was there anything unexpected/different from our FreeRTOS run loop?

In the console log, BTstack is sending HCI Reset three times before it gets a response. Then it sends HCI Read Local Version and gets no response. My guess is that there's an issue in the UART communication, either in the UART driver or the actual hardware.

Could you connect a logic analyzer to the full UART (rx,tx,rtx,cts) and post it here? We're interested to see if there's a response to the HCI Read Local Version eg.

[Robin-Velas]

Hi @mringwal,

First, thank you for your quick reply. I created the SafeRTOS version based on the FreeRTOS one, yes. The run loop function is logically identical. On the other hand, the SafeRTOS UART driver differs significantly from the FreeRTOS version.

It may be possible to connect a logic analyzer; I will get back to you once it's done, if applicable. In the meantime, I’ll look into the SafeRTOS UART adaptation to check whether I may have overlooked a critical step.

Just to confirm, at what stage in the process is the chip’s firmware updated? Is it after the HCI Read Local Version?

Have a nice day

[mringwal]

Hi

The FreeRTOS UART implementation (btstack_uart_block_freertos.c) is legacy. You should be able to use btstack_uart_block_embedded.c with FreeRTOS or SafeRTOS (it only relies on btstack_run_loop_poll_data_sources_from_irq()) and only have to implement hal_uart_dma.h for your platform.

The custom chip init starts after:

• HCI Reset
• HCI Read Local Version
• HCI Read Local Name
  and the first one would be to change the UART baudrate (if main baudrate != 0), followed by the ini script. Both read commands are used to identify the Controller.

Cheers

[mringwal]

Any news?

[Robin-Velas]

Hi @mringwal,

Yes, sorry for the late response. I did as you said, and used the btstack_uart_block_embedded.c instead with a custom implementation of hal_uart_dma.c (had some trouble in the way)

now, the gap_inquiry.c give another log, without EVT <= 0E 04 01 03 0C 00 but with a connection incomming. I am not sure how to interpret it, as it does not list bluetooth device but at least does not crash

Serial HCI log :

[00:02:18.592] LOG -- btstack_run_loop_safertos.c.224: run loop init, task 0x100295b0, queue item size 8
[00:02:18.599] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:02:18.606] LOG -- hci.c.5546: hci_power_control: 1, current mode 0
[00:02:18.612] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:02:18.620] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.165: hal_uart_dma_init: Standalone UART driver initialization
[00:02:18.632] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.203: hal_uart_dma_init finished
[00:02:18.750] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.263: hal_uart_dma_set_baud: 115200 bps configured
[00:02:18.759] LOG -- hci.c.8159: BTSTACK_EVENT_STATE 1
[00:02:18.763] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:02:18.770] CMD => 03 0C 00
[00:02:18.774] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:02:18.780] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 191
[00:02:18.787] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 184
[00:02:18.978] LOG -- hci.c.1814: Resend HCI Reset
[00:02:18.980] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:02:18.987] CMD => 03 0C 00
[00:02:18.990] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:02:18.999] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:02:19.006] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 182
[00:02:19.194] LOG -- hci.c.1814: Resend HCI Reset
[00:02:19.196] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:02:19.203] CMD => 03 0C 00
[00:02:19.206] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:02:19.213] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:02:19.220] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 184
[00:02:19.410] LOG -- hci.c.1814: Resend HCI Reset
[00:02:19.412] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:02:19.419] CMD => 03 0C 00
[00:02:19.422] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:02:19.429] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:02:19.436] EVT <= 04 0E 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00
[00:02:19.442] LOG -- hci.c.3807: Connection_incoming: 0C:03:01:04:0E:04, type 4
[00:02:19.449] LOG -- hci.c.329: create_connection_for_addr 0C:03:01:04:0E:04, type fc
...

But, again, I am not sure it is flashing the firmware into the chip at init. Is there a way to validate this?

Best regards

[mringwal]

Hi Robert. The stack is sending HCI Reset every 200 ms but gets no response. The "connection incoming" looks rather suspicious as all bytes there are part of HCI Event Command Complete for the HCI Reset.
Please connect a logic analyzer to the UART and compare to the hci dump output. In the UART trace, an HCI CMD starts with 0x01 while an HCI EVT uses 0x04.

[Robin-Velas]

Hello @mringwal (btw it's Robin, not Robert aha)

Okay, I see.

Unfortunately, I cannot connect a logic analyzer to inspect the UART directly. The SoM we are using (VAR-SOM-SOLO from Variscite) integrates the Bluetooth module internally. The UART interface between the i.MX6 CPU and the WiLink 8 chip is not accessible externally. Moreover, both the hardware schematic and the interconnects are partially undocumented due to confidentiality constraints imposed by the vendor.

In short -> the physical link is completely hidden and not instrumentable from our side.

Would there be any alternative way to confirm whether the firmware upload to the Bluetooth controller is actually taking place during initialization? Maybe via HCI responses or by detecting some expected behavior from the chip itself?

Thanks again for your support.

Best regards,
Robin

[mringwal]

Hi Robin (sorry for getting your name wrong before).

Thanks for the reference to your board - I can see the difficulty of connecting a logic analyzer :)
You could get a WI8 dev kit and connect it to a UART that is provided by the SOM as a kind of last resort.

Please follow these steps:

• make sure that there is a GPIO that toggles the mShutdown of the TWilink8. Pull it low to power off, wait 100 ms, pull it high to let it start up. wait 100 ms.
• flush your UART
• make sure hardware handshake is connected and enabled
• set it to 115200
• send the HCI Reset Command (01 03 0C 00)
• we now expect the response (04 0E 04 01 03 0C 00)

There are 2-3 HCI Commands after which the Chipset support for TI should send the init script. But without these commands working, there's no point wondering about the init script.

Cheers
Matthias

[Robin-Velas]

Hi @mringwal ,

I’ve carefully followed all of them to ensure a clean initialization

• pulled-low/high BLUTEOOTH_EN GPIO with 100ms timing.
• flushed UART
• unfortunately, can not check the handshake as I can not wire the SoM.
• set UART to 115200 baudrate
• the HCI reset command is sent
• Response is received

Since I can’t access the UART lines physically, I implemented a circular buffer directly inside the UART RX/TX ISRs. This buffer stores the last 1000 bytes sent and received, which I can dump at runtime for debugging.

From this dump, I confirm the following:

TX: the host repeatedly sends the HCI Reset command:

• 01 03 0C 00

RX: the controller replies with the expected response:

• 04 0E 04 01 03 0C 00

What’s puzzling is that the first few HCI Reset commands don’t receive any response, then suddenly the 4th one gets multiple Command Complete events at once, as if the controller had queued them internally.

Here's the full log of my application. May this help you?

full-log.txt

Best Regards,
Robin

[mringwal]

hm... maybe an external dev kit might still be needed to better understand the UART behaviour.

In your log, you get this:

EVT <= 04 0E 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00

EVT indicates the packet type 0x04. If we replace that, we get

04 04 0E 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00

It looks like the second byte got lost, which would have been 0x0e.
With the skipped 0x0e, we get 'connection request' as event instead of HCI Command Complete (0x0e) and it has 0x0e = 14 bytes of payload, which nicely explains why the output shows up after the 4th HCI Reset.

I have seen this before as a bug in the STM32 F4 driver. See
https://bluekitchen-gmbh.com/btstack-port-for-stm32-f4-discovery-board-with-cc256x/

There, the call to setup DMA to read a block of data over the UART had cleared everything, including the already received byte in the UART RX Data register. Please have a look into the UART driver to see if they clear the already received data for some unknown reasons.

If you cannot find anything there, I would suggest to verify with Variscite that RTS/CTS is of the Wilink 8 is connected.

If that's confirmed, you could test the UART driver against an external device. The external device should support RTS/CTS as well and could send a counter. If you get this counter by issuing 1-byte RX requests, everything is working. With the current observation, I would expect that every other byte gets lost.

Good luck
Matthias

[Robin-Velas]

Hi @mringwal,

Thank you again for your support and guidance. Following your recommendations, we have performed additional checks on our side:

• We verified the hardware configuration of the UART interface. CTS, RTS, TX, and RX lines are correctly routed and configured. Flow control is explicitly enabled in software, and we confirmed at runtime that both are properly set.

• We reviewed the UART RX interrupt handling logic. There is no mechanism in place that could clear the UART RX Data register before it is read. The RX is fully drained within the interrupt using a while-loop on the RDR bit.

• To confirm the integrity of the communication, we checked again the circular buffers in both the RX and TX interrupt routines, storing the last 1000 bytes. From these traces:

  TX -> the data clearly shows repeated HCI Reset commands: 01 03 0C 00.
  RX -> we observe a HCI Command Complete responses: 04 0E 04 01 03 0C 00.

  All packets appear well-formed, we do not observe any missing or shifted bytes.

Based on this, I believe the issue does not originate from the UART peripheral or driver. The captured data at the interrupt level is consistent and complete.

Please find attached the raw trace file (trace_rx_tx.txt) containing the full RX and TX logs.

trace_rx_tx.txt

Let me know if you would recommend focusing next on the HCI transport parsing or another layer.

Best regards,
Robin

[mringwal]

Hi Robin

Thanks for checking the lower layers here. If you receive 04 0E 04 01 03 0C 00 for every HCI Reset (even the very first one), then the lower layer looks good. If we assume that hci_transport_h4.c and btstack_uart_block_embedded.c are correct (as it has been used in most projects), the might be an issue in the hal_uart_dma.h implementation...

Let's verify this: HCI Transport H4 calls the btstack_uart_t implementation in btstack_uart_embedded.c for the first event in this sequence:

• read block(1) - to get the packet type -> 0x04
• read_block(2) - to get hci event header (event type and payload length)-> 0x0e 0x04
• read_block(4) - to get the hci event payload -> 01 03 0C 00.

After the third read block operation, the HCI Complete Event should be complete and we should have 04 0E 04 01 03 0C 00 in the hci_packet_buffer. You can use printf_hexdump(hci_packet, read_pos) to dump it in hci_transport_h4_block_read() to verify that.

Cheers
Matthias

[Robin-Velas]

Hello @mringwal,

First of all, I can confirm that even the very first HCI Reset received is 04 0E 04 01 03 0C 00. Following your suggestion, we instrumented hci_transport_h4_block_read with hexdump :

[00:00:09.621] LOG -- btstack_run_loop_safertos.c.224: run loop init, task 0x100295b0, queue item size 8
[00:00:09.627] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:00:09.635] LOG -- hci.c.5546: hci_power_control: 1, current mode 0
[00:00:09.641] LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
[00:00:09.648] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.179: hal_uart_dma_init: Standalone UART driver initialization
[00:00:09.660] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.217: hal_uart_dma_init finished
[00:00:09.779] LOG -- ./middleware/btstack/platform/safertos/hal_uart_dma.c.277: hal_uart_dma_set_baud: 115200 bps configured
[00:00:09.787] LOG -- hci.c.8159: BTSTACK_EVENT_STATE 1
[00:00:09.792] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:09.799] CMD => 03 0C 00
[00:00:09.802] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:09.809] HXDMP- btstack_util.c.281: 04
[00:00:09.812] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 188
[00:00:09.819] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 181
[00:00:10.007] LOG -- hci.c.1814: Resend HCI Reset
[00:00:10.009] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:10.016] CMD => 03 0C 00
[00:00:10.018] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:00:10.025] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:10.032] HXDMP- btstack_util.c.281: 04 0E
[00:00:10.036] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 181
[00:00:10.224] LOG -- hci.c.1814: Resend HCI Reset
[00:00:10.226] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:10.233] CMD => 03 0C 00
[00:00:10.235] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:00:10.242] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:10.249] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 185
[00:00:10.441] LOG -- hci.c.1814: Resend HCI Reset
[00:00:10.443] LOG -- hci.c.1873: hci_initializing_run: substate 0, can send 1
[00:00:10.450] CMD => 03 0C 00
[00:00:10.452] LOG -- btstack_run_loop_safertos.c.193: RL: wait with timeout 210
[00:00:10.459] LOG -- hci.c.1873: hci_initializing_run: substate 1, can send 0
[00:00:10.466] HXDMP- btstack_util.c.281: 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00
[00:00:10.473] EVT <= 04 0E 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00

According to your saying, something definitely seems off here as we have :

read block(1) - to get the packet type -> 0x04
read_block(2) - to get hci event header (event type and payload length)-> 0x04 0x0E
read_block(4) - to get the hci event payload -> 04 0E 04 01 03 0C 00 04 0E 04 01 03 0C 00.

Not sure what could cause this issue, but I am trying to investigate the hal_uart_dma.c at the moment. Thanks for pointing this out.

Best regards,
Robin

[mringwal]

Hi Robin. Looks like your read block code always copies all already received bytes into the requested buffer.
Maybe it needs to reset the number of buffered bytes or so :)

04
04 | 04 0E
04 | 04 0E | 04 0E 04 01 03 0C 00 ...

[Robin-Velas]

Hi @mringwal,

Here's an update on this issue.

We've made some progress and have now implemented a DMA-based (previously IRQ based) driver for the UART communication, using the i.MX6's SDMA controller. We are able to successfully send and receive data, and both TX and RX SDMA interrupts are triggering.

However, we're now facing a data corruption or desynchronization issue. It seems to be caused by UART Overrun Errors (ORE flag) happening intermittently. This shifts the receive buffer and causes the H4 parser to lose sync with the packet stream.

Here is a detailed log of the communication sequence:

LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
LOG -- hci.c.5546: hci_power_control: 1, current mode 0
LOG -- btstack_chipset_cc256x.c.164: cc256x: using custom init script
LOG -- ..hal_uart_dma.c.284: hal_uart_dma_set_baud: setting to 115200
LOG -- hci.c.8159: BTSTACK_EVENT_STATE 1
CMD => 03 0C 00
LOG -- hci.c.1814: Resend HCI Reset
CMD => 03 0C 00
LOG -- hci.c.1814: Resend HCI Reset
CMD => 03 0C 00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 04
LOG -- btstack_util.c.281: 01 03 0C 00
EVT <= 0E 04 01 03 0C 00
CMD => 01 10 00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 04
LOG -- btstack_util.c.281: 01 03 0C 00
EVT <= 0E 04 01 03 0C 00
LOG -- hci.c.2410: Command complete for different opcode 0c03, expected 1001, at substate 3
CMD => 01 10 00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 04
LOG -- btstack_util.c.281: 01 03 0C 00
EVT <= 0E 04 01 03 0C 00
LOG -- hci.c.2410: Command complete for different opcode 0c03, expected 1001, at substate 3
CMD => 01 10 00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 0C
LOG -- btstack_util.c.281: 01 01 10 00 06 00 00 06 0D 00 20 AC
LOG -- hci_transport_h4.c.200: Detected CC256x controller
EVT <= 0E 0C 01 01 10 00 06 00 00 06 0D 00 20 AC
LOG -- hci.c.2984: Manufacturer: 0x000d
CMD => 14 0C 00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 0C
LOG -- btstack_util.c.281: 01 01 10 00 06 00 00 06 0D 00 20 AC
EVT <= 0E 0C 01 01 10 00 06 00 00 06 0D 00 20 AC
LOG -- hci.c.2984: Manufacturer: 0x000d
LOG -- hci.c.2410: Command complete for different opcode 1001, expected 0c14, at substate 5
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E 0C
LOG -- btstack_util.c.281: 01 01 10 00 06 00 00 06 0D 00 20 AC
EVT <= 0E 0C 01 01 10 00 06 00 00 06 0D 00 20 AC
LOG -- hci.c.2984: Manufacturer: 0x000d
LOG -- hci.c.2410: Command complete for different opcode 1001, expected 0c14, at substate 5
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 06
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x06
LOG -- btstack_util.c.281: 0D
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x0d
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 20
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x20
LOG -- btstack_util.c.281: AC
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0xac
LOG -- btstack_util.c.281: 04
LOG -- btstack_util.c.281: 0E FC
EVT <= 0E FC 01 14 0C 00 06 00 00 06 0D 00 20 AC 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[00:00:33.120] LOG -- hci.c.2832: local name: �
CMD => 36 FF 04 C0 C6 2D 00
LOG -- hci_transport_h4.c.394: Baud rate command detected, expect command complete event next
LOG -- btstack_util.c.281: 01 14 0C 00 06 00 00
LOG -- btstack_util.c.281: 0D
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x0d
LOG -- btstack_util.c.281: 00
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x00
LOG -- btstack_util.c.281: 20
LOG -- hci_transport_h4.c.264: hci_transport_h4: invalid packet type 0x20
LOG -- btstack_util.c.281: AC

To provide more context, we have also monitored the RTS/CTS hardware handshake lines with a logic analyzer during this exact sequence. The trace below confirms that the lines are active and toggling as expected. Despite the active hardware flow control, the overrun and desynchronization still happen.

Time [s]	RTS	CTS
0.000000000	0	1
0.043302350	0	0
0.053879250	0	1
0.053880600	0	0
0.516137000	0	1
0.519017950	0	0
0.519198550	0	1
0.523184600	0	0
0.554154150	0	1
0.557559250	0	0
0.557739750	0	1
0.561727750	0	0
0.598822200	0	1
0.602100800	0	0
0.602281400	0	1
0.606258500	0	0
0.606960250	0	1
0.632661400	0	0
0.632755100	0	1
0.644281400	0	0
0.644375700	0	1
0.655913450	0	0
0.656007650	0	1
0.659815700	0	0
0.659996400	0	1
0.663982950	0	0
0.664163600	0	1
0.690385400	0	0
0.690479350	0	1
0.702004600	0	0
0.702098300	0	1
0.713637400	0	0
0.713731350	0	1
0.725270150	0	0
0.725364400	0	1
0.736901700	0	0
0.736995800	0	1
0.748532550	0	0
0.748626700	0	1
0.760162550	0	0
0.760256500	0	1
0.771795800	0	0
0.771889550	0	1
0.783428450	0	0
0.783522050	0	1
0.787333200	0	0
0.787514050	0	1
0.791500500	0	0
0.791855450	0	1
0.841351200	0	0
0.841531650	0	1
0.841574900	1	1
0.846813600	1	0
0.846831700	1	1
0.858428750	1	0
0.858473950	1	1
0.859649800	0	1
0.870116500	0	0
3.712614400	0	0

As you can see in the communication log, the stack sends HCI_Reset and sometimes gets the correct response. But after sending a new command like Read_Local_Version_Information (0x1001), it receives a stale Command Complete for the old HCI_Reset (0x0C03). This eventually leads to the H4 parser failing with invalid packet type errors.

We suspect this is caused by a race condition in our single-shot DMA implementation. The time between one DMA reception completing and the next one being armed is just enough to cause a UART FIFO overrun, corrupting the stream.

We have a couple of specific questions:

• Does this log pattern (especially the mismatched opcode response), combined with the fact that RTS/CTS is active, point to a known timing issue?
• Are the multiple HCI Reset + response a possible cause for this desynchronisation?
• Have you encountered similar desynchronization issues with the CC256x/WL18xx chipsets before? Is using the UART's IDLE Line interrupt to properly frame packets with DMA a common or recommended solution to prevent these kinds of overrun/timing issues on embedded platforms?

Thanks for your guidance.