Direct Test Mode Timer issue

RE: Direct Test Mode Timer issue

Paul772309 — Fri, 29 Sep 2023 09:54:00 GMT

The firmware is a very basic DTM type with UART port set appropriately for the nRF52810.

It looks like the timer is incorrectly set up. I don't know how this code passed QA.

I have replaced dtm_wait() with a simple delay loop aproximately of the deisgned delay (260us) and it appears to work fine, at least in transmit mode anyway.

RE: Direct Test Mode Timer issue

Håkon Alseth — Fri, 29 Sep 2023 07:25:28 GMT

Hi,

A dedicated tester shall use a minimum of 5 ms as a timeout, so this should be OK. Which dedicated tester are you testing against?

[quote user=""]currently imported[/quote]

If I understand correctly, dtm is included in a larger project on your end. Could you also test direct_test_mode as a standalone firmware to see if there's any integration issues?

Kind regards,

Håkon

RE: Direct Test Mode Timer issue

Paul772309 — Thu, 28 Sep 2023 12:05:23 GMT

It causes a UART timeout otherwise.

UART_POLL_CYCLE is 260us

MAX_ITERATIONS_NEEDED_FOR_NEXT_BYTE is 21 // 21*250 = 5460 is

However if we are expecting dtm_wait() to take 260us it actually takes 2500us (or whatever m_txIntervaluS is set to)

RE: Direct Test Mode Timer issue

Håkon Alseth — Thu, 28 Sep 2023 11:38:51 GMT

Hi,

[quote user=""]static uint32_t m_txIntervaluS = 2500; /**< Time between start of Tx packets (in uS). */[/quote]

Could you elaborate on why you have altered this parameter?

The protocol implementation will adjust dynamically based on the packet length in n*625, where n is between 1 and 4. Here's a table from Bluetooth Core spec v4.2, chapter 6/Part F/4.2:

(>=v5.0 of the core-spec writes the above with a formula instead of listing it in a table, ie. easier to understand the older spec)

Kind regards,

Håkon