BLE_hci coming back with incomplete/incorrect data for readReg

[EricB-ADI]

I don't know what is causing this but there seems to be some issues with the readReg command in the HCI, on at least the MAX32690 and I think the MAX32655.

It seems to be that the device works fine a few times, but will almost always come back with incorrect data and then the python cli tools crashes since the length isn't as expected.

btm-ci@wall-e:~/Workspace/eb/msdk/Tools/Bluetooth$ python3 BLE_hci.py "/dev/serial/by-id/usb-ARM_DAPLink_CMSIS-DAP_0409170211cd0dd400000000000000000000000097969906-if01" 
Bluetooth Low Energy HCI tool
Serial port: /dev/serial/by-id/usb-ARM_DAPLink_CMSIS-DAP_0409170211cd0dd400000000000000000000000097969906-if01
Monitor Trace Msg Serial Port: 
8N1 115200

>>> reset
2023-02-27 11:52:23.461550  > 01030C00
2023-02-27 11:52:23.673190  < 040E0401030C00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:32.927597  > 0101FF050200000020
2023-02-27 11:52:33.138517  < 040E060101FF000040
0x20000000: 0x____1
400
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:35.925245  > 0101FF050200000020
2023-02-27 11:52:36.136136  < 040E060101FF000040
0x20000000: 0x____1
400
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:38.793216  > 0101FF050200000020
2023-02-27 11:52:39.004155  < 040E060101FF000040
0x20000000: 0x____1
400
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:41.458582  > 0101FF050200000020
2023-02-27 11:52:41.669537  < 040E060101FF000040
0x20000000: 0x____1
400
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:43.253493  > 0101FF050200000020
2023-02-27 11:52:43.464319  < 040E060101FF000040
0x20000000: 0x____1
400
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:44.594600  > 0101FF050200000020
2023-02-27 11:52:46.806939  < 040E06012220000000
0x20000000: 0x____1
000
00
>>> readReg 0x20000000 0x2
02
2023-02-27 11:52:54.478393  > 0101FF050200000020
2023-02-27 11:52:54.783321  < 040E0401E5FF00
0x20000000: 0x____1
Traceback (most recent call last):
  File "BLE_hci.py", line 1428, in <module>
    args.func(args)
  File "BLE_hci.py", line 1074, in readRegFunc
    print(evtBytes[lineAddr], end="")
IndexError: list index out of range

You can see that the read reg command comes back identical, until it comes back with 040E06012220000000.

The program immediately crashes upon the next call. It seems that the last call was in fact about to return the correct data but the response was incomplete, and so an error occurs trying to access an index that doesn't exists.

[yc-adi]

1. In the BLE5_ctr/project.mk, change TRACE to 2. It will show you more information.
2. Try this to see if it would help or not. https://github.com/yc-adi/msdk_open/blob/14129d5e9c06eb9500bd7f104dbabf51034781ce/Tools/Bluetooth/BLE_hci.py#L313

[Jake-Carter]

@yc-adi @EricB-ADI is this still an open issue?

[EricB-ADI]

As far as I am aware, yes. However, we do not know if it is a BLE_hci.py problem or a Cordio/Task Scheduler problem. @AbbyWolf-ADI is working on a refactored version of the HCI for python, which may or may not rule out the python, but will at least improve the usability and rule out slow processing times of Python in regards to many print statements. When I was dealing with this, it was a multi level issue concerning the pyserial API, buffer overflows with the link layer for the HCI and more. It has not been cleared or even really investigated further, so we will leave it open for now.

However, I believe the primary user of this functionality is RF and I and only seems to show up on big reads. I have added a companion utility that uses PYOCD to control the radio, which was the main user of this, so if it persists, we may want to just deprecate or remove it until it becomes a bigger problem.

[yc-adi]

I agree. We may close this issue now.

[Jake-Carter]

As far as I am aware, yes. However, we do not know if it is a BLE_hci.py problem or a Cordio/Task Scheduler problem. @AbbyWolf-ADI is working on a refactored version of the HCI for python, which may or may not rule out the python, but will at least improve the usability and rule out slow processing times of Python in regards to many print statements. When I was dealing with this, it was a multi level issue concerning the pyserial API, buffer overflows with the link layer for the HCI and more. It has not been cleared or even really investigated further, so we will leave it open for now.

However, I believe the primary user of this functionality is RF and I and only seems to show up on big reads. I have added a companion utility that uses PYOCD to control the radio, which was the main user of this, so if it persists, we may want to just deprecate or remove it until it becomes a bigger problem.

Does the HCI trace actually encode in utf-8?

https://github.com/Analog-Devices-MSDK/msdk/blob/80e908b1ba2464e0dd62b449ba82b7feede6566e/Tools/Bluetooth/BLE_hci.py#L391

[EricB-ADI]

No, the HCI is a traditional opcode/data format in bytes. What you are seeing is a piece of code that allows you to basically steal the trace output, not the HCI data. This is where the actual HCI data is parsed.

https://github.com/Analog-Devices-MSDK/msdk/blob/80e908b1ba2464e0dd62b449ba82b7feede6566e/Tools/Bluetooth/BLE_hci.py#L230

[EricB-ADI]

Closing this issue. It seems to be resolved.