nrf5340 Sample Application hangs in Bootloader in Thingy91X

[Nicholas Papachristos]

I am using  the Thingy91X kit, and I am trying to make a sample 'hello_main" to work on the nrf5340. My project configuration is as follows:

Sample:         zephyr/samples/hello_world

SDK:              3.4.0

Toolchain:      nRF Connect SDK Toolchain v3.4.0

Board Target: thingy91x/nrf5340/cpuapp, NordicKits

SysBuild:         No sysbuild

Problem: 

When I click debug, the application hangs in bootloader. What do I need to do to debug my application?

JLinkGDBServerCL: SEGGER J-Link GDB Server V9.24a Command Line Version
JLinkGDBServerCL:
JLinkGDBServerCL: JLinkARM.dll V9.24a (DLL compiled Mar 5 2026 11:00:44)
JLinkGDBServerCL:
JLinkGDBServerCL: -----GDB Server start settings-----
JLinkGDBServerCL: GDBInit file: none
JLinkGDBServerCL: GDB Server Listening port: 63103
JLinkGDBServerCL: SWO raw output listening port: 2332
JLinkGDBServerCL: Terminal I/O port: 2333
JLinkGDBServerCL: Accept remote connection: localhost only
JLinkGDBServerCL: Generate logfile: off
JLinkGDBServerCL: Verify download: off
JLinkGDBServerCL: Init regs on start: off
JLinkGDBServerCL: Silent mode: on
JLinkGDBServerCL: Single run mode: on
JLinkGDBServerCL: Target connection timeout: 0 ms
JLinkGDBServerCL: ------J-Link related settings------
JLinkGDBServerCL: J-Link Host interface: USB
JLinkGDBServerCL: J-Link script: none
JLinkGDBServerCL: J-Link settings file: none
JLinkGDBServerCL: ------Target related settings------
JLinkGDBServerCL: Target device: nrf5340_xxaa_app
JLinkGDBServerCL: Target device parameters: none
JLinkGDBServerCL: Target interface: SWD
JLinkGDBServerCL: Target interface speed: 4000kHz
JLinkGDBServerCL: Target endian: little
JLinkGDBServerCL:
=thread-group-added,id="i1"
=cmd-param-changed,param="pagination",value="off"
0x000007b6 in ?? ()

Note: I have read somewhere that there are two options - 

• • Let the bootloader run and then attach the debugger after the app has started (attach mode instead of reset-and-halt), or
  • Disable MCUboot for debug builds if your board configuration allows it.

The first option does not work in my VS-Code. The second, 

[Edvin]

The bootloader on the thingy is indeed very sticky. It is not because of the HW itself, but because the board files for the Thingy91x is quite persistent that it needs a bootloader. 

Try adding these to the sysbuild.conf of your project:

SB_CONFIG_BOOTLOADER_NONE=y
SB_CONFIG_SECURE_BOOT_APPCORE=n
SB_CONFIG_SECURE_BOOT_NETCORE=n

If you later decide to try to build an application for the nRF9151 on the Thingy91x, you should add this to your sysbuild.conf:

SB_CONFIG_THINGY91X_NO_PREDEFINED_LAYOUT=y

I didn't test it now, but I did find these when I tried to use the Thingy91x for some BLE stuff a while ago. 

Best regards,

Edvin

[Nicholas Papachristos]

I created a basic application, that reaches main(). Now I need to to make it output uart data through to nRF Connect Serial Terminal. What configuration/code do I need to add to the project?

[Edvin]

This is where things start to get tricky. The Thingy91x doesn't have a debugger (which is the component on the DK that usually translates from UART to USB serial communication). So directly it is not possible to do this.

If you just need logging, I suggest that you try RTT logging instead. This only needs a debugger connected to the nRF5340. You see, on the DK, the on board debugger is connected via SWD in addition to some extra UART lines that it will interpret. This is why UART works out of the box on the DKs. This is not the case for the Thingys (this applies to all of them, Thingy52, Thingy53, Thingy91x).

There is an app called Connectivity bridge application that you can run on the nRF5340, which will read the UART pins from the nRF91, and translate it using the nRF5340's peripheral USB, to simulate what the debugger usually does. But this means that your nRF5340 will need to be running this application, and not the one that you are currently working on. 

Alternatively, you can look into it. It is found in v3.4.0\nrf\applications\connectivity_bridge

I have not disected this application, but perhaps you can use parts of it to write directly to the USB. But please note that whenever you halt the application (a breakpoint, for example), then the USB will stop replying and it will be disconnected. It also means that if your application crashes, you will not get an error log (like you would with UART). 

This is one of the pain points when working with the Thingy. Perhaps you can tell me whether you actually need UART output, or if you just want logging. In that case, I wouldn't really recommend the USB based logging, but rather RTT logging, as I mentioned earlier in this reply. This works a lot better e.g. if your application faults. 

Best regards,

Edvin

[Nicholas Papachristos]

Our product has both the 5340 and 9151 on board, and both have similar roles. The 5340 will do all the BLE stuff, and the UART0 is the comms channel between the 9151 and 5340 - just like in the Thingy. We can not use the application on the Thingy91X 5340 as is, so I am writing our own. I need some kind of UART comms for debugging the application, which finally be used to connect to the 9151, near completion of the development. I do not know what I am doing wrong, but I have not succeeded to set up the RTT link working, on VS-Code, or on the nRF-Connect for Desktop Serial Terminal. Can you give me detailed instructions how to set up the RTT? Is it a question of just the prg.conf contents?

[Edvin]

Hello,

I understand. If it helps, when you build for your custom HW, you probably will not be building with the Thingy91 board files, but create your own board files. So you don't need to mess around with disabling the bootloader on your custom board.

To enable UART logging, if your application uses LOG_INF() to log stuff, then it is simply a matter of adding/changing some Kconfigs (prj.conf contents). 

If you look at the sample: NCS\nrf\samples\bluetooth\peripheral_uart, this is an example on how to log via UART.

You need this set of Kconfigs:

# Config logger
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_PRINTK=n

Note: If you are currently logging using printk() or printf(), then you need to change it to LOG_INF() to be able to see it via RTT. In this case, you also need to add this close to the top of your main.c:

#include <zephyr/logging/log.h>

#define LOG_MODULE_NAME peripheral_uart
LOG_MODULE_REGISTER(LOG_MODULE_NAME);

And make sure that you regularly sleep in your main() loop, like it is done in the peripheral_uart sample (most samples, really)

int main(void)
{
    ...
    
	for (;;) {
		dk_set_led(RUN_STATUS_LED, (++blink_status) % 2);
		k_sleep(K_MSEC(RUN_LED_BLINK_INTERVAL));
	}
}

Then, you can use something like J-Link RTT Viewer to monitor the RTT logs. Make sure that you connect to the target after the application has started. And if you reset/reflash the device, you need to reattach the RTT viewer (by e.g. clicking F2).

Best regards,

Edvin