HI,
As stated in the topic I have found several misalignments/issues in the following setup:
NRF Connect Desktop (v5.3.2)
NRF Connect Desktop DTM (v3.1.4)
NRF CONNECT SDK (v3.4.0) nrf/samples/bluetooth/direct_test_mode app
1. NRF Connect Desktop DTM (v3.1.4) in TRANSMITTER mode allows setting Constant Carrier and UI indicates that the test successfully started.
The truth is that this configuration is rejected and the test is not running at all on the SoC. [00:16:47.625,549] <inf> dtm_tw_transport: Received 0x0000 command
Received 2-wire command 0x0000
Sending 2-wire event 0x0000
[00:16:47.625,671] <inf> dtm_tw_transport: Sending 0x0000 packet
[00:16:47.630,828] <inf> dtm_tw_transport: Received 0x0908 command
Received 2-wire command 0x0908
Sending HCI command to SDC
[00:16:47.631,072] <inf> dtm_tw_transport: Sending 0x0010 packet
[00:16:47.636,230] <inf> dtm_tw_transport: Received 0x0100 command
Received 2-wire command 0x0100
Sending 2-wire event 0x0000
[00:16:47.636,352] <inf> dtm_tw_transport: Sending 0x0000 packet
[00:16:47.650,604] <inf> dtm_tw_transport: Received 0x0300 command
Received 2-wire command 0x0300
Sending 2-wire event 0x0000
[00:16:47.650,726] <inf> dtm_tw_transport: Sending 0x0000 packet
[00:16:47.655,883] <inf> dtm_tw_transport: Received 0x0204 command
Received 2-wire command 0x0204
Sending 2-wire event 0x0000
[00:16:47.655,975] <inf> dtm_tw_transport: Sending 0x0000 packet
[00:16:47.661,102] <inf> dtm_tw_transport: Received 0x9303 command
Received 2-wire command 0x9303
Sending 2-wire event 0x0001
[00:16:47.661,224] <inf> dtm_tw_transport: Sending 0x0001 packet
Configuration is rejected here: https://github.com/nrfconnect/sdk-nrf/blob/aaf16b0020e579383e0632fabe10b564e90805f8/lib/dtm_twowire/dtm_twowire_to_hci.c#L283-L286
Are you planning to revert back the support of Constant Carrier?
2. NRF Connect Desktop DTM (v3.1.4) in RECEIVER mode allows setting the timeout to "No timeout".
On clicking the "Stop test" user receives a log "Transmitter test finished successfully. Received 6139 packets."
The problem is that the counter of packets does not accumulate in the "No timeout" mode basically making this option useless. It seems that the counter is limited to 2^14 in the desktop APP, but the real limit is https://github.com/nrfconnect/sdk-nrf/blob/aaf16b0020e579383e0632fabe10b564e90805f8/include/bluetooth/dtm_twowire/dtm_twowire_types.h#L64 (2^15)
I realize that to accurately count packets, the receiver needs to know the transmitter's packet length since that value dictates when the counter overflows. I am just wondering if there is a specific use case for enabling a "no timeout" setting during testing.
The implementation of nrf/samples/bluetooth/direct_test_mode underwent significant changes in NCS v3.4.0. In the previous version, v3.3.0, preventing counter overflow was simple and only required changing the rx_pkt_count variable from u16 to u32 via patch, allowing the receiver to operate for much longer durations in a single run. Is it possible to support extended periods in receiver mode with the new version?
3. I have encountered following SDC assertion when running the receiver mode (it comes from my custom DTM application, which is very similar to nrf/samples/bluetooth/direct_test_mode app. It only replaces twowire_transport with shell over RTT). Would you be so kind to provide some more context regarding this exact assertion?
SoftDevice Controller ASSERT: 167, 76
***** HARD FAULT *****
Fault escalation (see below)
ARCH_EXCEPT with reason 3
r0/a1: 0x00000003 r1/a2: 0x20006d00 r2/a3: 0x20006d00
r3/a4: 0x00000003 r12/ip: 0x00000000 r14/lr: 0x0001d691
xpsr: 0x21000011
Faulting instruction address (r15/pc): 0x0001d69e
Regards,
Pawel