No UART or CLI flasher on nrf52840dongle?

[mytzyiay]

I have developed a Zigbee application using the nrf52840 DK board + nRF Connect + Zephyr and it is working.  Now I am trying to move that app over to the nrf52840 dongle.  It didn't work on the first attempt, so now I need to debug it.  So far I have encountered a few issues:

1) On the DK board I could use pyocd to flash the device from the command line.  The only app I was able to find that is able to flash the dongle is called "Programmer" and it is a GUI app.  I saw some old instructions claiming that you could use nrfutil to flash the dongle, however this seemed to reference things that were only true in the old SDK.  nRF Connect doesn't even appear to ship nrfutil anymore.  Is there another way to flash the dongle board from the CLI or am I stuck using the GUI?

2) In my device tree for the dongle I wired up uart0 to pins P0.10 and P0.09.  I verified that these settings are reflected in the generated build/zephyr/zephyr.dts file.  However, when I connect a scope I do not see any transmissions in response to my log messages or printfs.  In my zephyr/.config file I have:

CONFIG_UART_INTERRUPT_DRIVEN=y
# CONFIG_UART_NS16550 is not set
# CONFIG_UART_PL011 is not set
# CONFIG_NRF_SW_LPUART is not set
CONFIG_NRFX_UART=y
CONFIG_NRFX_UART0=y
CONFIG_NRFX_UARTE=y
CONFIG_NRFX_UARTE0=y
# CONFIG_NRFX_UARTE1 is not set
CONFIG_HAS_HW_NRF_UART0=y
CONFIG_HAS_HW_NRF_UARTE0=y
CONFIG_HAS_HW_NRF_UARTE1=y
CONFIG_UART_CONSOLE=y
CONFIG_UART_CONSOLE_INIT_PRIORITY=60
# CONFIG_UART_CONSOLE_DEBUG_SERVER_HOOKS is not set
# CONFIG_UART_CONSOLE_MCUMGR is not set
CONFIG_UART_CONSOLE_INPUT_EXPIRED=y
CONFIG_UART_CONSOLE_INPUT_EXPIRED_TIMEOUT=15000
# CONFIG_UART_PIPE is not set
# CONFIG_UART_MCUMGR is not set
# CONFIG_UART_CONSOLE_LOG_LEVEL_OFF is not set
# CONFIG_UART_CONSOLE_LOG_LEVEL_ERR is not set
# CONFIG_UART_CONSOLE_LOG_LEVEL_WRN is not set
CONFIG_UART_CONSOLE_LOG_LEVEL_INF=y
# CONFIG_UART_CONSOLE_LOG_LEVEL_DBG is not set
CONFIG_UART_CONSOLE_LOG_LEVEL=3
CONFIG_UART_USE_RUNTIME_CONFIGURE=y
# CONFIG_UART_ASYNC_API is not set
# CONFIG_UART_LINE_CTRL is not set
# CONFIG_UART_DRV_CMD is not set
CONFIG_UART_NRFX=y
CONFIG_UART_0_NRF_UARTE=y
CONFIG_UART_0_ENHANCED_POLL_OUT=y
CONFIG_UART_0_INTERRUPT_DRIVEN=y
# CONFIG_UART_0_NRF_PARITY_BIT is not set
CONFIG_UART_0_NRF_TX_BUFFER_SIZE=32
CONFIG_UART_1_NRF_UARTE=y
CONFIG_UART_1_INTERRUPT_DRIVEN=y
CONFIG_UART_1_ENHANCED_POLL_OUT=y
# CONFIG_UART_1_NRF_PARITY_BIT is not set
CONFIG_UART_1_NRF_TX_BUFFER_SIZE=32
CONFIG_UART_ENHANCED_POLL_OUT=y
CONFIG_NRF_UARTE_PERIPHERAL=y
# CONFIG_UART_ALTERA_JTAG is not set
# CONFIG_UART_XLNX_UARTLITE is not set

3) The old SDK instructions for adapting an example to run on the dongle ( https://devzone.nordicsemi.com/guides/short-range-guides/b/getting-started/posts/nrf52840-dongle-programming-tutorial ) said to move the flash load offset to 0x1000, and to skip using the first 8 bytes of SRAM because that's used for interrupt forwarding.  In the default config for nrf52840dongle I see that FLASH_LOAD_OFFSET is 0x1000 which satisfies the former requirement.  But I also see that SRAM_OFFSET is 0 so my app might be clobbering 0x2000_0000 - 0x2000_0007.  Is that a problem?

[mytzyiay]

Also I have:

UART_CONSOLE_LOG_LEVEL(=3)
UART_CONSOLE_LOG_LEVEL_DBG(=n) "Debug"
UART_CONSOLE_LOG_LEVEL_ERR(=n) "Error"
UART_CONSOLE_LOG_LEVEL_INF(=y) "Info"
UART_CONSOLE_LOG_LEVEL_OFF(=n) "Off"
UART_CONSOLE_LOG_LEVEL_WRN(=n) "Warning"
UART_CONSOLE_MCUMGR(=n) "Enable UART console mcumgr passthrough"

[Simonr]

Hi

1. The Programmer app is the easiest way to program the nRF52840 Dongle, but you can also use a debugger if you're up for some soldering (described in the Dongle programming tutorial).

2. One red flag I noticed here. You say you're using pins P0.09 and P0.10. These are NFC pins by default I think. Please try adding the following CONFIG to your project: CONFIG_NFCT_PINS_AS_GPIOS=y

3. Where is SRAM_OFFSET set to 0 exactly? I would think this would be handled in the Dongles board files, but I can't seem to find anything on it. I can ask internally how this behaves if you'd like. I would suggest setting the RAM offset to 8 to be on the safe side at least.

Best regards,

Simon

[mytzyiay]

For flashing from the command line, I wound up using this procedure (which is not at all well-documented for nRF Connect users, IMO):

pip3 install nrfutil
cd build
nrfutil pkg generate --debug-mode --hw-version 52 --sd-req 0 --application zephyr/merged.hex /tmp/dfu.zip
nrfutil dfu usb-serial -pkg /tmp/dfu.zip -p /dev/cu.usbmodem* -b 115200

Had to guess at the --hw-version and --sd-req values since I didn't see any guidance for how to set them.  Other values failed.

I have debugging accessories on order but it will take a few days.  In particular I wasn't able to find a quick way (e.g. Amazon Prime) to get the 2x5 1.27mm debug header.  I tried running jumpers from SWDCLK/SWDIO to a cable attached to a J-Link Mini EDU but it looks like VREF, and maybe nRESET, are also required.  Too many pins for a hacky ad-hoc setup

CONFIG_NFCT_PINS_AS_GPIOS=y is the default setting in zephyr/boards/arm/nrf52840dongle_nrf52840/nrf52840dongle_nrf52840_defconfig and it is already enabled in my .config.

UART TX on pin 22 doesn't work any better than TX on pin 10.  I think something else is going wrong here.  Does nobody else ever try to enable a debug UART on the dongle boards?  This seems like a really basic request given the prevalence of printf() style debugging in the general population.

SRAM_OFFSET only seems to be getting used in zephyr/arch/x86/Kconfig for an emulated x86 system.  I think it has to be forced via Kconfig; I don't think that I can change it from menuconfig or editing .config directly.  So I guess the 8 byte offset is no longer necessary on the dongle boards after moving from the legacy SDK to nRF Connect?  The blinky example worked fine without it.

[Simonr]

Hi

At least the --sd-req is described by writing nrfutil pkg generate --help. The HW version I don't have an excuse for, but it seems you guessed correctly. I'll forward your feedback internally. Thank you!

Yes, it's hard to do debugging without the proper equipment. If you have a 10 pin cable and a 10-pin header you can also use the DK to debug the Dongle, but again this requires soldering on the 10 pin header onto the bottom of your nRF52 Dongle. Yes debugging using UART isn't straight-forward I'm afraid, since it's not really designed for development.

Best regards,

Simon

[mytzyiay]

Simonr said:

At least the --sd-req is described by writing nrfutil pkg generate --help.

I don't see anything that tells me what value to use for a blinky or Zigbee app that doesn't use SoftDevice at all?  The correct answer was "0x00" which does not appear in the documentation.  Every other value I tried caused a mismatch during flashing.

I'm not implementing BLE so nothing besides nrfutil has ever asked me about a SoftDevice.

--sd-req TEXT The SoftDevice requirements. A comma-
separated list of SoftDevice firmware IDs (1
or more) of which one must be present on the
target device. Each item on the list must be
a two- or four-digit hex number prefixed
with "0x" (e.g. "0x12", "0x1234"). A non-
exhaustive list of well-known values to use
with this option follows:
|s112_nrf52_6.0.0|0xA7|
|s112_nrf52_6.1.0|0xB0|
|s112_nrf52_6.1.1|0xB8|
|s112_nrf52_7.0.0|0xC4|
|s112_nrf52_7.0.1|0xCD|
|s113_nrf52_7.0.0|0xC3|
|s113_nrf52_7.0.1|0xCC|
|s130_nrf51_1.0.0|0x67|
|s130_nrf51_2.0.0|0x80|
|s132_nrf52_2.0.0|0x81|
|s130_nrf51_2.0.1|0x87|
|s132_nrf52_2.0.1|0x88|
|s132_nrf52_3.0.0|0x8C|
|s132_nrf52_3.1.0|0x91|
|s132_nrf52_4.0.0|0x95|
|s132_nrf52_4.0.2|0x98|
|s132_nrf52_4.0.3|0x99|
|s132_nrf52_4.0.4|0x9E|
|s132_nrf52_4.0.5|0x9F|
|s132_nrf52_5.0.0|0x9D|
|s132_nrf52_5.1.0|0xA5|
|s132_nrf52_6.0.0|0xA8|
|s132_nrf52_6.1.0|0xAF|
|s132_nrf52_6.1.1|0xB7|
|s132_nrf52_7.0.0|0xC2|
|s132_nrf52_7.0.1|0xCB|
|s140_nrf52_6.0.0|0xA9|
|s140_nrf52_6.1.0|0xAE|
|s140_nrf52_6.1.1|0xB6|
|s140_nrf52_7.0.0|0xC1|
|s140_nrf52_7.0.1|0xCA|
|s212_nrf52_6.1.1|0xBC|
|s332_nrf52_6.1.1|0xBA|
|s340_nrf52_6.1.1|0xB9|