• State
  • Locked Locked
  • Replies 14 replies
  • Subscribers 42 subscribers
  • Views 521 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1837MOD: Bluetooth Power On Issues

Jonathan
Prodigy 110 points
Part Number: WL1837MOD

We have two separate products that use TI wireless modules.  One uses the C2564MODN and the other uses the WL1837MOD.  We noticed a difference in behavior between the C2564MODN version and the WL1837MOD version regarding the success of powering-on the chip and also the amount of time it takes to enable Bluetooth.  Below are recorded times of successful power-ons of each stack:

 

C256x:

- BluetopiaPM daemon restart: 1.152 sec

- Set Power-On command sent and completed by BluetopiaPM: 3.414 sec

- Post-power-on configuration commands sent and completed by BluetopiaPM: 0.419 sec

   - Set baud rate

   - Set name

   - Set class-of-device

   - Set CODEC

   - Register authentication

   - Register Headset Profile event callback

   - Register Hands-Free Profile event callback

   - Enter discovery

- Total startup time with no retries: 4.987 sec

 

WL18xx:

- BluetopiaPM daemon restart: 7.250 sec

- Set Power-On command sent and completed by BluetopiaPM: 9.215 sec

- Post-power-on configuration commands sent and completed by BluetopiaPM: 0.283 sec

- Total startup time with no retries: 16.749 sec

You can see that the WL18xx daemon takes ~6 more seconds to start, and then ~6 more seconds to power-on the chip as compared to the C256x version.  Additionally, we never saw the need with the C256x build to implement any retry mechanism (i.e., it always seems to start without any issue); so the C256x BT-on time appears to be always around 5 seconds.  However, one of the weird issues we had to resolve was making sure the WL18xx build's bluetooth would start reliably — our solution was any time the Set Power command failed we would reinitialize the BluetopiaPM daemon and retry the Set Power command.  While testing this I found that the WL18xx bluetooth will always eventually start up, but there is a good chance (e.g., ~17% of the time) the BluetopiaPM startup will run into a failure and the process needs to be reset.  Normally the failure occurs with the power-on command, so we are looking at seeing the need to retry after 16.5 seconds and then performing the retry.  So a single-retry version of starting it would be around 33 seconds; if a second retry is needed we are looking at 50 seconds or so.  Statistically over 80% of the time it should be about 16 seconds for bluetooth to come up on WL18xx.

Is there a better way to retry the Set Power-on command once it fails — as near as I can tell if this failure occurs the only way to recover is by restarting the daemon which is pretty time-consuming.  Additionally, is there any way to speed up the WL18xx start-up times?

  • 0
    TI__Intellectual 1145 points

    Hi Jonathan, could you tell me more about your setup, such as host, kernel version, and which service pack version are you running for WL18xx? 

    If you are able to probe the pins to WL18xx, could you ensure that the proper start up sequence's occur as described in the datasheet in section 8.21.2 and below?

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    Hi Daniel,

    The host is an OMAP2.  Linux Kernel 3.2.102 with some backports applied for WiFi.  The service pack for WL18xx is R8.7_SP3.

    I confirmed that the start up sequence meets the requirements per the datasheet. 

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, this is the service pack I was referring to, WL18XX-BT-SP Driver or library | TI.com, the file contained, TIInit_11.8.32.bts is the initialization script sent to the chips ROM on bootup, the latest version is V4.8, marked as P2.148 in the file itself. If you could make sure you are uploading the latest version of this script that would be appreciated. 

    On the topic of speeding up the WL18xx start-up times to my knowledge there is solution, perhaps you could speed up the UART communication but that time should be negligible.

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    Hi Daniel,

    The bts file we are using is TIInit_11.8.32BT4.2.bts.  Although the file is binary, I opened it in a text editor and saw these pieces of text:

    Compatibility             : 185x/189x 8.0.32 ROM"
    Last Updated            : 28-Jun-2021  03:25:12”
    Version                     : TI_P2.148”
    Notes                        : Use this script on Diamond ROM device only (FW v8.0.32)”

    Should we be using TIInit_11.8.32.bts without the "BT4.2"?  Our stack supports BT 5.1 so seems like this bts is for BT 4.2 only?

    Regarding the HCI baud rate, the device defaults to 115200 baud but we change to 3000000 baud during startup by using a vendor specific command.

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, could you try using the non BT4.2 version? If that does not work, we may need to take logs of the HCI commands using these tools to further debug the issue: WILINK-BT_WIFI-WIRELESS_TOOLS Application software & framework | TI.com

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    Hi Daniel, we just tried the non BT4.2 bts file version and still observe the same power on issue.  I took logs using the BT logger and was able to capture the issue.  Power on took around 75 seconds due to our retry mechanism.  The log verified Package ID is P2.148.  Can you review the log and let me know if you see any issues?  Link below:

    BT log .lgr file

  • 0 in reply to Jonathan
    Prodigy 110 points

    Please analyze this log instead.  I forgot to add the HCI/LMP logs to the previous ones.  Thanks.

    BT Logger and HCI/LMP logs 

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, looking through the log all three power on sequences are exactly identical in the HCI Commands sent and the Event Complete messages sent back meaning the firmware should not be the issue here. That however, makes debugging this issue more difficult.

    One thing that can be experimented with that may, though only slightly, improve boot time or even alleviate the failure issue is to speed up/slowdown the UART interface upon boot. Because the .bts file contains HCI commands you can use HCITester (included with the WILINK-BT_WIFI-WIRELESS_TOOLS) to add Send_HCI_VS_Update_Uart_HCI_Baudrate 0xFF36, UART_BAUD to the script and run at that baud rate rather than waiting to update the speed later on.

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    Where in the bts file should I put the Send_HCI_VS_Update_Uart_HCI_Baudrate 0xFF36 command?  At the top before the first command (Send_HCI_VS_Start_VS_Lock 0xFE37, 0x08, 0x20)?

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, yes please place the command at the very start of the script before the VS_Lock.

    Optionally you can also add this command: (Com_SetParams 115200, 1). This command has nothing to do with the WiLink device, it updates the configuration in HCITester in case you are using that for testing.

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    Hi Daniel,

    When the WL1837MOD is powered on, it has an internal default baud rate of 115200.  The baud rate on the host must also be set to 115200 for communication to take place.  After power-on when the BTS file download to the module has started at 115200 baud, if the HCI_VS_Update_Uart_HCI_Baudrate command is at the top of the BTS file to change the HCI baud rate to 3000000 let's say, then how would the host know to change the baud rate on the host com port as well to 3000000?  Unless I am missing something here I don’t see how this will work because the HCI baud rate would be at 3000000 but the host would still be at 115200.  Please advise. 

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, yes the host will need to update its own baudrate after that command is sent. If need be you could just send the Update_HCI_Baudrate before the BTS file is sent. 

  • 0 in reply to Daniel Olis
    Prodigy 110 points

    We use BluetopiaPM to manage the chip, so how are we able to adjust the baud rate before the BTS file is downloaded? 

    There doesn't seem to be a way for us to modify the UART speed until after Bluetopia finishes downloading the BTS into the module, which at that point is too late.  We want to change the baud rate initially to speed up the process.

  • 0 in reply to Jonathan
    TI__Intellectual 1145 points

    Hi Jonathan, you could send a UART message that looks like the HCI command/packet. This link contains all the vendor specific commands and the packet structure for HCI: CC256x VS HCI Commands (ti.com)