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: Need to call SetDevicePower(1) several times to power on BLE device

Prodigy 130 points

Replies: 16

Views: 282

Part Number: WL1837MOD

Hello, 

I succeeded in integrating TI BluetopiaPM stack into our Linux based firmware.

On boot, the init and event callback registration always work right away, but I have to call SetDevicePower(1) several times to power on the device (see log below). Sometimes, I have to retry up to 10 times!?

Could you please help me solve this problem? In other words, how to make sure SetDevicePower(1) always returns success?

FYI, I tried 2 different baud rates: 115200 and 3000000, but it didn't help.

Thank you and best regards,

--VT

LOG:

BTPM_Initialize() Success: 0.
DEVM_RegisterEventCallback() Success: 5.
>>> BLE Initialized!!!
==============WAKE UP
>>> calling SetDevicePower(1) RETRY 0
echo 960 > /sys/class/gpio/export
echo out > /sys/class/gpio/gpio960/direction
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
BT COMM PORT (/dev/ttyPS1): 1
Changing HCI baud rate to 3000000
Status: Executing BTS Script /lib/firmware/TIInit_11.8.32.bts.
echo 0 > /sys/class/gpio/gpio960/value
DEVM_PowerOnDevice() Failure: -4, Unknown Error.
==============WAKE UP
>>> calling SetDevicePower(1) RETRY 1
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
BT COMM PORT (/dev/ttyPS1): 2
Changing HCI baud rate to 3000000
Status: Executing BTS Script /lib/firmware/TIInit_11.8.32.bts.
echo 0 > /sys/class/gpio/gpio960/value
DEVM_PowerOnDevice() Failure: -4, Unknown Error.
==============WAKE UP
>>> calling SetDevicePower(1) RETRY 2
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
BT COMM PORT (/dev/ttyPS1): 3
Changing HCI baud rate to 3000000
Status: Executing BTS Script /lib/firmware/TIInit_11.8.32.bts.
echo 0 > /sys/class/gpio/gpio960/value
DEVM_PowerOnDevice() Failure: -4, Unknown Error.
==============WAKE UP
>>> calling SetDevicePower(1) RETRY 3
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
BT COMM PORT (/dev/ttyPS1): 4
Changing HCI baud rate to 3000000
Status: Executing BTS Script /lib/firmware/TIInit_11.8.32.bts.
echo 0 > /sys/class/gpio/gpio960/value
DEVM_PowerOnDevice() Failure: -4, Unknown Error.
==============WAKE UP
>>> calling SetDevicePower(1) RETRY 4
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
echo 0 > /sys/class/gpio/gpio960/value
echo 1 > /sys/class/gpio/gpio960/value
BT COMM PORT (/dev/ttyPS1): 5
Changing HCI baud rate to 3000000
Status: Executing BTS Script /lib/firmware/TIInit_11.8.32.bts.
Status: BTS Script successfully executed.
DEVM_PowerOnDevice() Success: 0.
>>> !!! BLE DEVICE ON !!!

Device Powered On.
DEVM_QueryLocalDeviceProperties() Success: 0.
>>> DisplayLocalDeviceProperties:
BD_ADDR: 74E1822FD3A4
HCI Ver: 0x0008
HCI Rev: 0x0000
LMP Ver: 0x0008
LMP Sub Ver: 0xAC0D
Device Man: 0x000D (Texas Instruments Inc.)
Device Flags: 0x80000000
BLE Address Type: Resolvable Random
BLE BD_ADDR: 5FC1327DEFBC
COD: 0x1C0424
Device Name: WL18xx Device
Disc. Mode: TRUE , 0x00000000
Conn. Mode: TRUE , 0x00000000
Pair. Mode: TRUE , 0x00000000
LE Scan Mode: FALSE, 0x00000000
LE Adv Mode: FALSE, 0x00000000

16 Replies

  • Have you verified that the Bluetooth power-up sequence of the WL18xx is followed properly every time the SetDevicePower is called in your system? 

    Reference : Figure 5-5 in module datasheet 

    Best regards,

    Vihang

  • In reply to Vihang Parmar:

    No, I haven't.

    Just curious, what's the reason behind your question?

    What to do if the power-up sequence is not followed properly?

    Thanks,

    --VT

  • In reply to VT Nguyen:

    Hi VT,

    VT Nguyen
    Just curious, what's the reason behind your question?

    Improper power-up sequence is one of the most common reason for this type of startup failure, especially for custom hardware. So at the minimum, this step will help you identify if the root cause is a HW issue or a SW bug.

    VT Nguyen
    What to do if the power-up sequence is not followed properly?

    It depends on your findings from the investigation of the power-up sequence. If the root cause is a HW issue, we may be able to use a workaround in SW (e.g. manual delay to ensure proper timing). If it is a SW bug, this test will help us identify which step of the initialization is failing (e.g. sending the first command over UART, changing the UART baud rate after the first command or during waking up from sleep-mode). I might be getting ahead of myself here. Let's first isolate if it is a HW issue of a bug in the SW.

    Best regards,

    Vihang

  • In reply to Vihang Parmar:

    Hi Vihang,

    Many thanks for your clear explanations.

    FYI this WL1837MOD chip has been integrated into our product (no more prototype) for years. And WiFi has been working perfectly so far. Now we are trying to use BLE for new features on our product.

    Upon your suggestion, I talked to the electrical engineer who designed the board about probing some pins (as shown in Figure 5-5 of the DS). Unfortunately, the 2 pins we can probe on our board are: BT_UART_DEBUG (#43) and WL_UART_DEBUG (#42). 

    So I can't really check if there's a HW issue or not.

    Instead, is it possible for you to provide a debug version of TIInit_11.8.32.bts? That way, hopefully we can figure out where the init or power-up sequence fails ...

    Thanks,

    --VT

      

  • In reply to VT Nguyen:

    VT,

    VT Nguyen
    Instead, is it possible for you to provide a debug version of TIInit_11.8.32.bts? That way, hopefully we can figure out where the init or power-up sequence fails ...

    The initialization fails in your system before the host downloads the initscript(*bts file) to the controller. So a debug version of the service-pack is not going to help here.

    Please provide the Bluetooth firmware logs from the BT_UART_DEBUG pin during the initialization. To keep it easy enough to analyze, I would request capturing a new .lgr log file for each failed and successful attempts so we can have a good comparison. 

    Here is the user's guide on how to capture these firmware logs : http://www.ti.com/lit/pdf/swau058

    Best regards,

    Vihang

  • In reply to Vihang Parmar:

    Hi,

    I succeeded in downloading wl18xx_bt_sp_v4.4.zip and installing the tools on my Win 10 laptop.

    The BT Logger has been successfully set up as shown in the attached screenshot.

    But unfortunately, nothing was captured by the Logger.

    I probed the BT_UART_DEBUG pin and saw "something" (signal) on the oscilloscope.

    I also used Tera Term to capture the log, but it's not readable (see teraterm.log attached).

    Any ideas?

    Thanks,

    --VT

    4403.teraterm.log

  • In reply to VT Nguyen:

    VT,

    VT Nguyen

    I probed the BT_UART_DEBUG pin and saw "something" (signal) on the oscilloscope.

    I also used Tera Term to capture the log, but it's not readable (see teraterm.log attached).

    Any ideas?

    This is expected since the logs coming out of the BT_UART_DEBUG pin are not ASCII strings. They are command opcodes and relevant parameters. The logger tool is needed to interpret them in real-time before saving them in *.lgr log file.

    VT Nguyen
    The BT Logger has been successfully set up as shown in the attached screenshot.

    I would double check the settings described in the SWAU058 document. If everything is set up correctly, A properly configured logger (both software and hardware) would generate the initialization logs like the Figure 15 in this document. 

    Best regards,

    Vihang

  • In reply to Vihang Parmar:

    Hi Vihang,

    I followed the instructions to install again the BT Logger on another Win10 laptop, but still no luck! :-(

    In the swau058d.pdf document, section 3.2 Capturing the logs, step 2: Power up the Bluetooth ® device and enable the BT controller...

    What does "enable the BT controller" actually mean?

    In my setup, I just turn on my device including the TI WiFi/BT chip. I do see the debug traces on the serial log showing the BLE init from the firmware, but nothing on the BT Logger.

    Thanks,

    --VT

        

  • In reply to VT Nguyen:

    4744.ble_logs.zipble_logs.zipPlease ignore my previous question about "enable the BT controller".

    I finally succeeded in capturing 2 logs for the OK and NOK cases!!!

    The problem was due to the fact that the 2 BT_UART_DBG and WL_UART_DBG pins were swapped on my board !!!???

    Hope we can now figure out the root cause.

    Looking forward to hearing from you very soon.

    Thanks,

    --VT

  • In reply to VT Nguyen:

    Did, you try stopping/killing SS1BTPM daemon, in each iteration? If not, please give it a try.. 

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.