CYW4373E(LAIRD STERLING LWB5+) libbtstack stuck in firmware downloading

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

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:

  1. btsnd_hcic_reset (in libbtstack)
  2. bt_post_reset_cback
  3. bt_start_fw_download
  4. cybt_prm_download
  5. wiced_bt_dev_vendor_specific_command(HCI_VSC_DOWNLOAD_MINI_DRV...)
  6. 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.

  1. cybt_prm_send_next_patch
  2. 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

  1. 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.

0 Likes
1 Solution
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

@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.

See https://github.com/Infineon/stm32-connectivity/blob/master/Middlewares/Third_Party/pal/targets/TARGE...

On our host, the lptim1 is clocked to 75MHz and drivers the rx_task like crazy.

View solution in original post

0 Likes
11 Replies
Owen_Zhang123
Moderator
Moderator
Moderator
5 questions asked 500 solutions authored 250 sign-ins

Could you share the whole hci log when the problem happens?

0 Likes
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

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.

 

0 Likes
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

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.

0 Likes

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.

0 Likes

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.

0 Likes

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. 

https://github.com/Infineon/stm32-connectivity/blob/release-v1.3.0/Middlewares/Third_Party/btstack-i...

0 Likes

Hi @Owen_Zhang123 , I will check that and get back to you.

0 Likes
lock attach
Attachments are accessible only for community members.
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

@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)

 

0 Likes
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

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.

0 Likes
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

Hi @Owen_Zhang123 I confirm that your btstack-integration code has the above problem.

The open sourced code is:

https://github.com/Infineon/stm32-connectivity/blob/master/Middlewares/Third_Party/btstack-integrati...

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.

0 Likes
HarveyZ
Level 2
Level 2
First solution authored 5 sign-ins 10 replies posted

@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.

See https://github.com/Infineon/stm32-connectivity/blob/master/Middlewares/Third_Party/pal/targets/TARGE...

On our host, the lptim1 is clocked to 75MHz and drivers the rx_task like crazy.

0 Likes