Problem Run and Test DTM at customer hardware with nRF52840

RE: Problem Run and Test DTM at customer hardware with nRF52840

Håkon Alseth — Wed, 16 Feb 2022 09:31:14 GMT

Hi MatthK,

I am quite certain that the firmware itself is alright, unless you have changed core behavior of the DTM source code, or any of your clock sources are problematic (ie. not present or incorrectly loaded)

The usual problem when DTM is misbehaving is physical connection issues. This can be incorrect pin connected to the external USB/UART converter for instance, or that the pin itself is physically connected to another device on the custom PCB.

[quote user="matthk"]When I try to connect my custom hardware containing nRF52840 and the USB/UART bridge (FT230X) to the nRF Connect Software at the PC I click at 'Select Device'; then I get 'Unknown 0000... FFFF'. When selecting this device the error 'Can not communicate with device. Make sure it is not in use by another application and that it has a Direct Test Mode compatible firmware.' appears.[/quote]

You are certain that there's no external terminal (putty, teraterm, etc) that is claiming the COM port?

[quote user="matthk"]Then I have measured at TXD at the FT230X, but I can see only 3.3V (probably idle mode) appear. Could this voltage creates problems as the nRF52840 is supplied with 3.0V? 3 years ago with nRF52832 and the same conditions every worked well.[/quote]

This is not a problem.

[quote user="matthk"]I have started a sweep at the nRF Connect for Windows with connected PCA10056 board; I can see the running channel at 0dBM at the (Transmitter) screen as expected. So I suppose that at the tester side everything runs as expected. Unfortunately nothing to see at the Receiver screen...[/quote]

When transmitting, you should keep the device static at one channel. This is because there's no synchronization between tester and DUT when it comes to what channel they're communicating on.

That being said, if you can successfully start and stop a test, then the DTM is running properly.

Have you tried programming your custom.hex file to the nRF52840-DK, then connect your FTDI to the specific pins to see if works on a DK?

I changed the uart_init function to reflect your pin out:

static void uart_init(void)
{   
    uint32_t err_code;
    const app_uart_comm_params_t comm_params =
      {
          30, /*RX_PIN_NUMBER,*/
          12, /*TX_PIN_NUMBER,*/
          RTS_PIN_NUMBER,
          CTS_PIN_NUMBER,
          APP_UART_FLOW_CONTROL_DISABLED,
          false,
          DTM_BITRATE
      };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_error_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);

    APP_ERROR_CHECK(err_code);
}

And tested this on my nRF52840-DK, and it entered DTM modes without any issues.

Kind regards,

Håkon

RE: Problem Run and Test DTM at customer hardware with nRF52840

matthk — Tue, 15 Feb 2022 14:23:54 GMT

Hi Håkon,

I have started a sweep at the nRF Connect for Windows with connected PCA10056 board; I can see the running channel at 0dBM at the (Transmitter) screen as expected. So I suppose that at the tester side everything runs as expected. Unfortunately nothing to see at the Receiver screen...

Then I have measured at TXD at the FT230X, but I can see only 3.3V (probably idle mode) appear. Could this voltage creates problems as the nRF52840 is supplied with 3.0V? 3 years ago with nRF52832 and the same conditions every worked well.

When I try to connect my custom hardware containing nRF52840 and the USB/UART bridge (FT230X) to the nRF Connect Software at the PC I click at 'Select Device'; then I get 'Unknown 0000... FFFF'. When selecting this device the error 'Can not communicate with device. Make sure it is not in use by another application and that it has a Direct Test Mode compatible firmware.' appears.

I have still the impression that the Hardware configuration in the target electronics is not ok, but in which file (after calling uart_init()) can I check that?

When stepping through uart_init() I see that the structure comm_params contains the right Pins for RxD and Txd, RTS and CTS are not used; the Flow Control is disabled and the baudrate parameter contains 536871040 which corresponds to 19200 Baud as far as I know. Up to the end of uart_init() (breakpoint) also the supply current is quite low, so the problem seems to come later...

The custom_board.h contains (TX testwise moved from P0.17 to P 0.30):

#ifndef BOARD_CUSTOM_H
#define BOARD_CUSTOM_H

#ifdef __cplusplus
extern "C" {
#endif

#include "C:\SVN\sources\SDK_17_1\modules\nrfx\hal\nrf_gpio.h"

// LEDs definitions for HW Version 'h'
#define LEDS_NUMBER 0
#define BUTTONS_NUMBER 0

#define RX_PIN_NUMBER 12
#define TX_PIN_NUMBER 30 // testwise, normally 17
#define CTS_PIN_NUMBER UART_PIN_DISCONNECTED // 8
#define RTS_PIN_NUMBER UART_PIN_DISCONNECTED // 30
#define HWFC false

#ifdef __cplusplus
}
#endif

#endif // BOARD_CUSTOM_H

In the makefile I have the following settings:

# Libraries common to all targets
LIB_FILES += \

# Optimization flags
OPT = -O3 -g3
# Uncomment the line below to enable link time optimization
#OPT += -flto

# C flags common to all targets
CFLAGS += $(OPT)
CFLAGS += -DBOARD_CUSTOM
CFLAGS += -DBSP_DEFINES_ONLY
CFLAGS += -DCONFIG_GPIO_AS_PINRESET
CFLAGS += -DFLOAT_ABI_HARD
CFLAGS += -DNRF52840_XXAA
CFLAGS += -mcpu=cortex-m4
CFLAGS += -mthumb -mabi=aapcs
CFLAGS += -Wall -Werror
CFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
# keep every function in a separate section, this allows linker to discard unused ones
CFLAGS += -ffunction-sections -fdata-sections -fno-strict-aliasing
CFLAGS += -fno-builtin -fshort-enums

# C++ flags common to all targets
CXXFLAGS += $(OPT)
# Assembler flags common to all targets
ASMFLAGS += -g3
ASMFLAGS += -mcpu=cortex-m4
ASMFLAGS += -mthumb -mabi=aapcs
ASMFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
ASMFLAGS += -DBOARD_CUSTOM
ASMFLAGS += -DBSP_DEFINES_ONLY
ASMFLAGS += -DCONFIG_GPIO_AS_PINRESET
ASMFLAGS += -DFLOAT_ABI_HARD
ASMFLAGS += -DNRF52840_XXAA

# Linker flags
LDFLAGS += $(OPT)
LDFLAGS += -mthumb -mabi=aapcs -L$(SDK_ROOT)/modules/nrfx/mdk -T$(LINKER_SCRIPT)
LDFLAGS += -mcpu=cortex-m4
LDFLAGS += -mfloat-abi=hard -mfpu=fpv4-sp-d16
# let linker dump unused sections
LDFLAGS += -Wl,--gc-sections
# use newlib in nano version
LDFLAGS += --specs=nano.specs

What can I check next?

Kind regards,

MatthK

RE: Problem Run and Test DTM at customer hardware with nRF52840

Håkon Alseth — Mon, 14 Feb 2022 14:48:03 GMT

Hi MatthK,

Thank you for explaining the setup.

When you flash DTM on your custom device, with P0.12/P0.17 as the RXD/TXD, the TXD should be active low (ie. high when idle), while the RXD pin will float unless connected to a TXD on the FTDI-side. You can scope the pins to see if there's any activity at all on the pins.

You can also try different GPIOs if you want, as the default board pca10056 uses p0.12 as a button, unless you have redefined this in your boards file (note: BOARDS define must also be redefined in the Makefile).

Easiest for quick testing different GPIOs is to just change the main.c::uart_init() function and hardcode the comm_params struct directly, and recompile.

Are you able to setup any test in the PC application using the FTDI+custom board setup? If no, what is the error that you see on the PC side?

Kind regards,

Håkon

RE: Problem Run and Test DTM at customer hardware with nRF52840

matthk — Mon, 14 Feb 2022 13:31:07 GMT

Hi Håkon,

the DUT (Device under Test) is our target electronics containing a nrf52840 where I have the problem to make run the DTM application - a standard application with BLE (Using S140) use works perfect.

The tester side is the PCA10056 with the flashed hex-file direct_test_mode_pca10056.hex from SDK17.1\examples\dtm\direct_test_mode\hex; as supposed I use this with nRF Connect for Desktop - DTM application.

Kind regards,

MatthK

RE: Problem Run and Test DTM at customer hardware with nRF52840

Håkon Alseth — Mon, 14 Feb 2022 09:31:16 GMT

Hi MatthK,

[quote user="matthk"]

the TXD/RXD pins are connected to an UART/USB bridge FT230XS; this electroncs we have already used for the first certification 3 years ago with nRF52832; so I assume that this should do also with nRF52840.

Concerning the point of fail of the DTM process: I would like to investigate more on that problem: Is there any point in the SW where the hardware should be completely initialized? Then I could set a breakpoint and see if the supply current is still ok or increased...

[/quote]

What is the tester-side setup at your end?

Are you using a dedicated tester, or is there a nRF-kit acting as the tester (using nRF connect for desktop->DTM application) ?

Kind regards,

Håkon

RE: Problem Run and Test DTM at customer hardware with nRF52840

matthk — Mon, 14 Feb 2022 08:39:36 GMT

Hi Håkon,

Kind regards,

MatthK

RE: Problem Run and Test DTM at customer hardware with nRF52840

Håkon Alseth — Fri, 11 Feb 2022 13:29:39 GMT

Hi Matt,

[quote user=""]As 3 years ago I first tried to use the nRF Connect at my PC with the stick, the old nRF51 stick was compatible and worked well with nRF Connect. In the forum I read that with the nRF52840 Dongle this will not work, so I use the PC10056. I have erased this board and flashed the file direct_test_mode_pca10056.hex from SDK17.1\examples\dtm\direct_test_mode\hex. When powering this board I see a LED flickering; when selecting this board at nRF Connect (in Windows) the flickering changes a little bit; when I click at Start test the LED's behaivour changes a little bit. It seems that this works, but can I make a test with the nRF52840 Dongle for verifying?[/quote]

The nrf52840dongle, pca10059, does not have a example project specifically for DTM. This must then be manually created, as described in this thread:

https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial

[quote user=""]

Now coming to the main problem: I use a customer elecronics where our standard Software with BLE traffic (using SDK13; soon we will change to Zephyr) runs perfect. So I can assume that the HW is ok. Parallel to our standard project I have created a DTM project; here I use SDK17.1 to be sure that we meet the latest requirements for the radio certification. I have created a custom_board.h file which just contains:

#define LEDS_NUMBER 0
#define BUTTONS_NUMBER 0

#define RX_PIN_NUMBER 12
#define TX_PIN_NUMBER 17
#define CTS_PIN_NUMBER UART_PIN_DISCONNECTED // 8
#define RTS_PIN_NUMBER UART_PIN_DISCONNECTED // 30
#define HWFC false

RX is connected to P0.12 and Tx to P0.17.

I can build the project; when setting a breakpoint to the first line current_time = dtm_wait();in the endless-loop for (;;) the system behaves as expected. Pressing then several times F6 (Step over) will result in toggling between the mentioned current_time = dtm_wait() line and the next if(app_uart_get(&rx_byte) != NRF_SUCCESS) instruction; this seems still fine for me. When I press then 'Run' I see the supply current heavily increasing to about 4 times of the current before; when I start a test in nRF Connect I see just the same as if the customer board is switched off. When pressing 'Suspend' the program flow stops at the if(nrf_timer_event_check(..) function in dtm_wait().

A breakpoint set to the last line SystemCoreClockUpdate(); in void SystemInit(void) in system_nrf52.c is never reached...

What is here wrong?

[/quote]

Given that you are able to debug the main application, it shows that debugging in general is working. The SystemCoreClockUpdate() is essentially an empty function updating only one variable, it might be that a optimized application updates it as a part of the .data (non zero initialized RAM) section instead.

I am not sure what is happening here, because based on your description, the firmware runs as expected. Could you share a bit more info on where the DTM process fails on the tester side?

How did you connect your TXD/RXD pin to the upper tester, through a USB/UART bridge?

Kind regards,

Håkon