nrf5340 Sample Application hangs in Bootloader in Thingy91X

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Edvin — Wed, 05 Aug 2026 11:14:56 GMT

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

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Wed, 05 Aug 2026 09:38:31 GMT

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?

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Edvin — Tue, 04 Aug 2026 13:23:54 GMT

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

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Tue, 04 Aug 2026 12:48:00 GMT

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?

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Edvin — Mon, 03 Aug 2026 13:49:55 GMT

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

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Mon, 03 Aug 2026 11:45:04 GMT

Could you provide the recommended method for building a thingy91x/nrf5340/cpuapp debug image without MCUboot/TF-M involvement?

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Mon, 03 Aug 2026 11:23:48 GMT

By the way, I have a SEGGER J-link, and I can see the nrf5340 on NRF Connect for Desktop V5.3.2, Programmer v4.8.0.

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Mon, 03 Aug 2026 11:16:56 GMT

I am using the Thingy91 as a development kit. In a few weeks, we shall have our own board with a 9151 and 5340 on it. The demo kit has a nice application on it, and we want to create an application that uses most of the features in Thingy91X. At this moment, I have no choice. I do not understand why developing on the demo kit should be impossible. It seem to be stuck on a trivial issue - mainly due to lack of precise information how to overcome this particular issue. If the the only way would be to sign the image so that the bootloader could run it, so be it - this problem should be solvable too.

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Nicholas Papachristos — Mon, 03 Aug 2026 10:53:50 GMT

For the second option, I tried CONFIG_BOOTLOADER_MCUBOOT=n in zephyr/.config, but it did not make a difference.

RE: nrf5340 Sample Application hangs in Bootloader in Thingy91X

Edvin — Mon, 03 Aug 2026 10:52:50 GMT

Hello,

Working directly on the nRF5340 on the Thingy91x is not trivial. If you intend to write an application for the nRF5340 (or any other nordic BLE chip) I strongly suggest that you get hold of an nRF5340DK, or even better, the nRF54L15 DK. Is there any particular reason why you are using the nRF5340 specifically? And is there any particular reason why you are using the Thingy91X for developing BLE applications?

And if you have a good reason, can you let me know what exact HW you have access to? Do you have an external debugger? What device are we seeing the log from now? Is it the nRF5340 on the Thingy, or the nRF91 on the thingy?

[quote user=""]Let the bootloader run and then attach the debugger after the app has started (attach mode instead of reset-and-halt), or[/quote]

If you do have a debugger, you can do this. Click the 3 dots on the right hand side of "debug" in VS code, and select "Attach Debugger to Target". Although, I am not convinced this will help.

[quote user=""]Disable MCUboot for debug builds if your board configuration allows it.[/quote]

probably the easiest, but it is not straight forward on the Thingy either. Again, it depends on what kind of setup you have. External debugger?

Best regards,

Edvin