BLE Testing functions do not work properly #42534
Assignees
Labels
area: Bluetooth Controller
area: Bluetooth
bug
The issue is a bug, or the PR is fixing a bug
priority: low
Low impact/importance bug
Comments
|
Since you are using a linux distribution, ensure that Bluetooth Daemon is disabled, i.e. Also, there are some work in progress related to Direct Test Mode support in Zephyr, please follow #42300 |
|
@piotrParf can you please enclose a full |
|
I see nothing specia at btmon at the moment. Will investigate tomorrow. Up to today it looks like this. The problem also occurs when i call ll_test_tx() from firmware on my own not just while connected to hci or so. It was showed made so it could be replicated using HCI- UART example. Can you help me with formatting this ? :) I am not familiar how to hide/collapse this big chunk of data... |
|
From what I found up to date: |
|
Why in ll_test.c the isr_tx() is written in such a manner ? What I observed is the issue happens when difference between t and s is so large the while loop takes so long time that the t value is being written to timer in the "past" due to sampling of s far before end of while loop. Because of this radio timer invokes after timer overflows which takes a lot of time. Isn`t it better to replace the while loop with below code ? What do you think @cvinayak? For me it solves the issue of "stopped/very big period of packet sending during test". I do not know how it behaves on other platforms than nrf5340. |
|
It is an old implementation, the difference should not be large and the while loop should not iterate too many times such that it is not able to meet the next 625us. But I do see that under rollover of the timer count, the difference will be incorrectly very high. Your suggestion is good, but do add implementation to handle rollover scenario. Please send a pull request with your changes, we can continue to refine the changes in that PR. |
|
should I do pool request on current dev branch or some 2.7 lts ? I am not familiar with working with such a huge system. |
|
You should send the pull request to the latest |
|
I created a pull request. There is another issue which activates this bug. It is in default config definitions of BLE for nrf5340. I observed that radio_tmr_end_get() always returns zero in 2.7 LTS. The defines of radio_tmr_end_capture(void) are changed in radio.c at current main branch. Changing this to current main branch makes proper invocation of radio_tmr_end_capture(). I found that this is related to CONFIG_BT_CTLR_TIFS_HW_SUPPORT=y and CONFIG_BT_CTLR_RADIO_ENABLE_FAST=y not setting up CONFIG_BT_CTLR_TIFS_HW in 2.7 LTS. |
piotrParf
pushed a commit
to piotrParf/zephyr
that referenced
this issue
Feb 17, 2022
…ite big it can hapen that while loop will take a long time. This leads to setting up start of a radio timer before current timer value. This then leads to invocation of a timer after rollout and this will lead to very large delay in sending packet. It fixes for me a issue zephyrproject-rtos#42534. Signed-off-by: Piotr Parfeniuk [email protected]
|
We are also trying to use the DTM functionality of zephyr BLE controller with nRF53. We are facing problem where |
|
@dhananjaygj |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using Nordic nRF5340DK with Zephyr 2.7.0 LTS SDK. I am using built in j-link and SES(Segger Embedded Studio) to debug. I also use emptyapp from nordic on the application core and example HCI uart from /samples/bluetooth/hci_uart and set CONFIG_BT_CTLR_DTM_HCI=y in prj.conf
I am using nrf testing applications like RSSI Viewer and DTM test demos on Windows and code for nRF5340DK is being build in linux Debian enviroment.
The issue:
When I use HCI command LE Transmitter Test the test packets stop transmitting after certain time or packet count(around ~4000).
I cant find any workaround to this issue, yet it is needed for Bluetooth hardware testing.
The DTM sample app from nRF Connect SDK works as expected but they are not compatible with Bluetooth stack.
To Reproduce
Build an Empty Application Core from Nordic, to give control for network core, from their repository.
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf5340/empty_app_core/README.html
Build an HCI-UART application with setting: CONFIG_BT_CTLR_DTM_HCI=y
1.Run SES and load HCI-UART example application to the network core,
2.load empty application core to the network core,
3.connect the UART of nrf5340 to rtt-uart output of NRF5340DK to proceed with attaching HCI-BLE to linux
4. On linux(debian in my case) run as su : btattach -B /dev/ttyACM1 -S 1000000 -P h4 &
5. now open the RSSI Viewer application on another Nordic developement kit and start it to watch the BLE radio spectrum.
6. now on the linux run the hci tool and send command: hcitool -i hci1 cmd 0x08 0x1e 0x02 0x20 0x00 0x00 (HCI_LE_Transmitter_Test
[v2] from specification BLE 5.2 Vol 4, Part E) It should start sending packets with PRBS9 at channel 2 with length of 32 bytes, until issuance of the command hcitool -i hci1 cmd 0x08 0x1f (LE_Test_End)
Expected behavior
The Bluetooth stack should transmit test packets continuously until receiving LE_Test_End command from HCI interface, yet it spontaneously stops transmitting sooner than the command LE_Test_End.
Additional info
The same issue happens when in network core app directly is being called ll_test_tx() function from subsys/bluetooth/controller/ll_sw/nordic/lll/lll_test.c - the packets suddenly stop transmitting after some time.
The text was updated successfully, but these errors were encountered: