- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hardware: STM32H743 Nucleo connects to LWB5+ via UART
Software: https://github.com/Infineon/stm32-connectivity/releases/tag/release-v1.3.0 tailored to the above host
Call sequences:
- btsnd_hcic_reset (in libbtstack)
- bt_post_reset_cback
- bt_start_fw_download
- cybt_prm_download
- wiced_bt_dev_vendor_specific_command(HCI_VSC_DOWNLOAD_MINI_DRV...)
- cybt_prm_command_complete_cback
After that the host software was stuck in the firmware downloading process. The host kept sending the first chunk of the firmware but couldn't move forward.
The response message from the radio was probably dropped somewhere in libbtstack so cybt_prm_command_complete_cback was not called again which maintains the state machine of the firmware downloading process.
- cybt_prm_send_next_patch
- wiced_bt_dev_vendor_specific_command(HCI_VSC_WRITE_RAM...)
-- the first chunk of the firmware was seen on the wire and the radio chip responsed
host tx:
0x01, 0x4C, 0xFC, 0x46, 0x00, 0xB5, 0x21, 0x00, 0x42, 0x52, 0x43, 0x4D, 0x63, 0x66, 0x67, 0x53,
0x00, 0x00, 0x00, 0x00, 0x32, 0x00, 0x00, 0x00, 0x01, 0x01, 0x04, 0x18, 0x92, 0x00, 0x00, 0x00,
0x03, 0x06, 0xAC, 0x1F, 0x00, 0xA0, 0x73, 0x43, 0x00, 0x01, 0x1C, 0x42, 0xB5, 0x21, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x00
host rx:
0x04, 0x0e, 0x04, 0x01, 0x4c, 0xfc, 0x00
- cybt_hci_rx_task was waked up and the above rx message was processed by the task correctly
--handle_hci_rx_event
--wiced_bt_process_hci_events
I couldn't figure out what happened in the libbtstack but cybt_prm_command_complete_cback was not called again.
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Owen_Zhang123 The problem is caused by lptim clock source.
Your code assumes the lptim is clocked to 32768Hz or 32KHz but the assumption may not be correct.
On our host, the lptim1 is clocked to 75MHz and drivers the rx_task like crazy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Could you share the whole hci log when the problem happens?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Looks like the forum doesn't accept long reply. Try to separate it into several pieces.
My debugging trace setup is like following:
void host_stack_platform_interface_init(void)
{
...
host_stack_platform_if.pf_hci_trace_cback_t = NULL;
...
}
I tried to get it working but without success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Traffic on the wire:
btsnd_hcic_reset
tx:0x01 0x03 0x0c 0x00
rx:0x04 0x0e 0x04 0x01 0x03 0x0c 0x01
HCI_VSC_DOWNLOAD_MINI_DRV?
tx:0x01 0x2e 0xfc 0x00
rx:0x04 0x0e 0x04 0x01 0x2e 0xfc 0x00
HCI_VSC_DOWNLOAD_MINI_DRV?
tx:0x01 0x2e 0xfc 0x00
rx:0x04 0x0e 0x04 0x01 0x2e 0xfc 0x00
HCI_VSC_WRITE_RAM?
tx:
0x01,
0x4C, 0xFC, 0x46, 0x00, 0xB5, 0x21, 0x00, 0x42, 0x52, 0x43, 0x4D, 0x63, 0x66, 0x67, 0x53, 0x00,
0x00, 0x00, 0x00, 0x32, 0x00, 0x00, 0x00, 0x01, 0x01, 0x04, 0x18, 0x92, 0x00, 0x00, 0x00, 0x03,
0x06, 0xAC, 0x1F, 0x00, 0xA0, 0x73, 0x43, 0x00, 0x01, 0x1C, 0x42, 0xB5, 0x21, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x00,
rx:0x04 0x0e 0x04 0x01 0x4c 0xfc 0x00
The last two message were repeatedly seen on the wire.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The 0x01,0x4C, 0xFC command is write RAM. The minidriver FW needs several write cycle to complete. So you will see many write ram command. It is normal if the content is different.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Owen, Thanks for your reply.
I understand that the host send firmware data to the radio piece by piece. In the 1.3.0 package the firmware itself is in a C byte array(w_bt_fimware_controller.c->brcm_patchram_buf). I clearly saw many pieces in the byte array. The first piece is 70(0x46) bytes, the second piece is 204(0xCC) bytes, etc.
The problem is that the host was repeatedly sending the first piece which is 70 bytes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It seems the host doesn't enter the send next packet loop. Please refer to the readme file to enable the trace log and set the trace level to CYBT_TRACE_LEVEL_DEBUG
to see which step is stuck.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Owen_Zhang123 Here is the BTSpy log regarding the issue.
My debug logging setting is like the following:
#define INITIAL_TRACE_LEVEL_MAIN (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_SPIF (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_HCITX_TASK (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_HCIRX_TASK (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_HCI_DRV (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_HCI_LOG (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_MEMORY (CYBT_TRACE_LEVEL_DEBUG)
#define INITIAL_TRACE_LEVEL_PRM (CYBT_TRACE_LEVEL_DEBUG)
#ifdef ENABLE_BT_SPY_LOG
#define INITIAL_TRACE_LEVEL_STACK (CYBT_TRACE_LEVEL_MAX)
#else
#define INITIAL_TRACE_LEVEL_STACK (CYBT_TRACE_LEVEL_ERROR)
#endif
#define INITIAL_TRACE_LEVEL_APP (CYBT_TRACE_LEVEL_ERROR)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I probably know what the problem is now. The cybt_hci_rx_task is driven by the lptimer and every time when the lptimer times out the rx_task sends a HCI_RESET to the queue of the cybt_hci_tx_task and flooded the queue of the tx_task. Once tx_task starts to run, it sends out all the accumulated HCI_RESET messages and drives its state machine into wrong state.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi @Owen_Zhang123 I confirm that your btstack-integration code has the above problem.
The open sourced code is:
1. The libbtstack's time out value for HCI_RESET looks too short. Because the code is in the library I couldn't figure out what the value is and how it works.
2. The cybt_hci_tx_task was scheduled out when it tried to log to debug task. When it was scheduled in again and started to fetch from its message queue, the queue was full already and flooded with HCI_RESET command.
3. The tx_task calls cybt_check_and_resume_hci_tx after it wrote to the uart peripheral. The cybt_check_and_resume_hci_tx function only acknowledged the libbtstack by calling wiced_bt_stack_indicate_lower_tx_complete when tx_task's queue or heap usage is less than 50%. But the behavior is wrong. Whatever the queue or heap usage was, the HCI command had been written to the peripheral already.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Owen_Zhang123 The problem is caused by lptim clock source.
Your code assumes the lptim is clocked to 32768Hz or 32KHz but the assumption may not be correct.
On our host, the lptim1 is clocked to 75MHz and drivers the rx_task like crazy.