• State
  • Locked Locked
  • Replies 16 replies
  • Subscribers 42 subscribers
  • Views 1672 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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

VT Nguyen
Prodigy 180 points

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

  • 0
    TI__Mastermind 29361 points

    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

  • 0 in reply to Vihang Parmar
    Prodigy 180 points

    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

  • 0 in reply to VT Nguyen
    TI__Mastermind 29361 points

    Hi VT,

    VT Nguyen said:
    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 said:
    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

  • 0 in reply to Vihang Parmar
    Prodigy 180 points

    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

      

  • 0 in reply to VT Nguyen
    TI__Mastermind 29361 points

    VT,

    VT Nguyen said:
    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

  • 0 in reply to Vihang Parmar
    Prodigy 180 points

    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

    Fullscreen 4403.teraterm.log Download 
    











































���
























































?H?���	
Ak�@K	B@@?@IIIIIII?bY
N���
@?
�D�J�C��N���D
��I���E
��IE
��IB��B��
B�I
B��
B�IB�I
B�IB��
B��B�I
B�L�BI	N��K@H�@����i Bi��Yb������@I\?]
?
B��������A�]

B�!?	��@@ ]
?$
B��(��CJ ]

B
����@?o_��
B
��Y��4T ]

BD���
D��HU� ]
$
B�??�	NID��L K��o��BBB@@@IIIIIIIIIIIIIII
D\






H���������"���#��3А����I�F��
���H��D�_��L�F���°���Fu���u���	H��3?����T@�
��D��I���L��
�[�����
���IB��IF
�������D@�I�G�G���������� ���"k
IBk6TB���@�]
��G��]�����]B��I@�]� ��]"��[@�\�????�]H����]J��A�]�����]��G��]�Y�D����]0�BITIDT�M��� 
��ɸ��"k
Bk��BC�]0
��AP��]0��2����??�] G����] A��J��?�] � ��] � P��\I��]0O��}A�]0�°�CP��]0����]0���P��]��D��]C��B��???���]"��M��]P��L��]H��2@�]P��O���] ��@���]� ���]� 0A�]� ���]N����]D��I��]\��'I��]
��I��]j��	I��]e���I��] K�BI\�����????�����]C�ITIDT=��I_i`����.��YM ?�
�	�NI��@B?o?��1������IK
K?��I[

K��I[

���T�[
��L[��
\\�KD�L@
�bI�
k
	
#i����1����H�����H�d��I	��I	��IZ
��I,
KBA���	IKA�����d��?�M���Ec_
�¶\��\�FNO?q?b������jؐ���µ�M�z���{�]0�0�0
�
0
��?����?�?�
?
��0
�0�0�?
�D�J	�?�?��
?�
��?���0��0�0
�
0
��?�?�?��?��?���?�Io�
�\������IoCy�
�����IoB���
H��H�����IoL�i�
�����Ioǰ��
T������Io����
E���
����Io���
�M�M
���Io��}�
�s����0�0�?�?��?�?�?�?����?���?����?�����?
�
��?�?�?�
�
?��
�?�?��
�?�
�
��?�?�?��
�
��?��?�0��?�?���?���?��?���?�?���?�?�?��0���?�?�?�
?
���?��?�?
�
���������
?�?�
?��?�?
�?�
?
��?�?��?�?�?�?��?��?�?�?�?��?���?���?���?�������?�?�?�?���
?
��






















��
�

















��




�








��








���



��
��
�







������
�


�������






���






���
��������������������������
��


��
����

��
��
��
��


��

�
�
��


�



������������������������������������
�
���
������
���
�
������

���
�
�
�
��






�����
��
��
��
���������









���
�
�
��������
�
��������
�������������������
��

�
�
��

������
����

��
��
��
���
�
������
��

�
�
��
���������



��������
































�
��Io@�@B�?�\K�����P\�?o�\�M2�����������Io��@BK�.?
�D����D_
���w











































?H?

  • 0 in reply to VT Nguyen
    TI__Mastermind 29361 points

    VT,

    VT Nguyen said:

    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 said:
    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

  • 0 in reply to Vihang Parmar
    Prodigy 180 points

    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

        

  • 0 in reply to VT Nguyen
    Prodigy 180 points

    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

  • 0 in reply to VT Nguyen
    TI__Mastermind 27090 points

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

  • 0 in reply to Hari Nagalla
    Prodigy 180 points

    Sorry, I don't understand your request.

    On boot, I start SS1BTPM by doing: /usr/sbin/ss1btpm &

    Now you want me to kill it, correct?

    If so, I should not start it in the first place, no?

  • 0 in reply to VT Nguyen
    Prodigy 180 points

    Hi,

    Did you have a chance to analyze the 2 logs I captured ?

    Please let me know what's wrong in the power-up sequence.

    Thanks,

    --VT

  • 0 in reply to VT Nguyen
    TI__Mastermind 27090 points

    You seem to be using older BT service pack. Can, you try with latest service pack, along with the Bluetopia stack.

    http://www.ti.com/tool/WL18XX-BT-SP

    http://www.ti.com/tool/TI-BT-4-2-STACK-LINUX-ADDON

    If this does not help.. We need to get some debug, trace events from Bluetopia stack to check, where exactly it is failing..

    Which, host processor are you using? 

    Thanks

  • 0 in reply to Hari Nagalla
    Prodigy 180 points

    Hi Hari,

    Thank you for your suggestion, but after downloading the files you mentioned, they are exactly the SAME version I've been using!

    Could you please let me know how to get debug traces, events from Bluetopia stack to figure out the root cause?

    Thanks,

    --VT

  • 0 in reply to Hari Nagalla
    Prodigy 180 points

    One more thing, the host processor is Arm Cortex A9.

  • 0 in reply to VT Nguyen
    TI__Mastermind 27090 points

    Can, try with 'strace'? you can compare successful and failed cases for any differences in tty/uart system call sequence.

    Thanks