nRF Connect Direct Test Mode re-connection issue if you remove the debugger

[Branden Sheffield]

I am having an issue using the DTM app in nRF Connect.  It is the latest version of the app (v3.3.0 as of this writing).  The issue is that if I disconnect the debug lines (Rx and TX) and the hardware remains powered it will continue to transmit/receive as expected.  However, when I reconnect the debug lines to control the radio again I get the following error from the DTM app.

"Can not communicate with device. Make sure it is not in use by another application and that is has a Direct Test Mode compatible firmware."

The only work around I have found so far is to find some way to interrupt the processor - either reprogramming it, reading the memory back or a reset.

Once I do this it will respond as normal.  The DTM app works well if I just leave the debugger connected, but that isn't ideal for performing certain regulatory tests where you would like to remove any long cables and such from your product during the test.

Is there way to add a reset command in the DTM firmware and in the DTM app, so if it gets into a state like this, you could simply reset it?  Then this allows a testing facility to only need access to the debug lines for the DTM application and not the programming pins.

FYI I have only tested/verified this on some custom hardware that I have developed so far.  I have tried various things like unplugging my debug port only from the computer, from the device etc... they all result in the same behavior.

Thanks!

[Kenneth]

I suspect there is an assert occurring here due to noise on the UART lines, this will cause UART framing error. In the uart_error_handle() I can see that the DTM application will assert by default if there is APP_UART_COMMUNICATION_ERROR. In addition I suspect that app_error_fault_handler() is configured with DEBUG enabled, thereby it will not execute NVIC_SystemReset().

I guess there are several workarounds possible here, for instance you can in the uart_error_handle() simply call NVIC_SystemReset() directly if there is an APP_UART_COMMUNICATION_ERROR.

Alternatively you may also look into adding external pull up resistor (e.g. 10kohm) on the UART RXD and TXD pins to avoid the APP_UART_COMMUNICATION_ERROR to occur in the first place.

Best regards,
Kenneth

[Branden Sheffield]

Thanks for the suggestions!  I like those ideas, I don't have space on my custom HW to add the 10ks but could probably modify my debug boards easily and test this.  I may try the suggestion to add the reset command in the uart error handle first however as a quick work around.

thanks again for the quick feedback!

PS - I still think a reset feature may be nice the DTM app as a future feature request

[Kenneth]

Hi,

If you search for nrf_gpio_cfg_input() in nrfx_uarte.c and nrfx_uart.c you should be able to replace NRF_GPIO_PIN_NOPULL with NRF_GPIO_PIN_PULLUP for the RXD pin (which I suspect is the problematic one).

Best regards,
Kenneth