No RTT output when enabling mcuboot

[mackz]

I am working on a custom board featuring a nrf9160, when i run the zephyr hello_world application with:

CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y 
CONFIG_SEGGER_RTT_BUFFER_SIZE_UP=4096
CONFIG_LOG_MODE_IMMEDIATE=y

Everything works and i can see the output in JLinkRTTViewer. But when i enable:

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_MCUBOOT_BOOTUTIL_LIB=y

i get no output at all. The application seems to be running since i can see the current consumption changing.


I found this: Cannot see both bootloader and application RTT output #53544 Closed which seems to be an issue with only being able to see either mcuboot logs or applications logs which is not really the case for me. I cant see anything.

But i tried to add the patches suggested by giansta but it still does not work. This is part of what i got from objdump on the .elf file:

objdump -t zephyr.elf | grep RTT
2000c568 l    d  _RTT_SECTION_NAME      00000000 _RTT_SECTION_NAME
00000000 l    df *ABS*  00000000 SEGGER_RTT.c
2000c578 l     O _RTT_SECTION_NAME      00001000 _acUpBuffer
2000c568 l     O _RTT_SECTION_NAME      00000010 _acDownBuffer
2000c568 l       _RTT_SECTION_NAME      00000000 $d
00000000 l    df *ABS*  00000000 SEGGER_RTT_zephyr.c
00000001 g     O *ABS*  00000000 CONFIG_SEGGER_RTT_SECTION_CUSTOM
0002843d g     F text   00000058 SEGGER_RTT_WriteNoLock
000284d9 g     F text   00000030 SEGGER_RTT_Init
00000000 g     O *ABS*  00000000 CONFIG_SEGGER_RTT_MODE
2000c568 g       _RTT_SECTION_NAME      00000000 __rtt_buff_data_start
00000001 g     O *ABS*  00000000 CONFIG_SEGGER_RTT_SECTION_CUSTOM_NAME
2000c580 g       _RTT_SECTION_NAME      00000000 _image_ram_start
2000d578 g     O _RTT_SECTION_NAME      000000a8 _SEGGER_RTT
2000d620 g       _RTT_SECTION_NAME      00000000 __rtt_buff_data_end

I have also tried to disable logs from mcuboot by adding a child_image/mcuboot.conf with:

CONFIG_USE_SEGGER_RTT=n
CONFIG_LOG_BACKEND_RTT=n
CONFIG_MCUBOOT_UTIL_LOG_LEVEL_OFF=y
CONFIG_LOG=n

but this also did not work.

I am on Ubuntu 22.04.5 LTS
using nrf connect sdk 2.6.1 and J Link V7.94i.

[Einar Thorsrud]

Hi,

Can you start by verifying that the application is actually started? For instance by toggling a GPIO, or checking something else that is observable from the outside?

Other than that, RTT is tricky because it uses a buffer in RAM that is allocated build time, so it will typically move when you re-build the application. Therefore, you normally always need to open the RTT viewer again after flashign new firmware. (The RTT viewer seraches for a magic pattern, and decides on where the buffer is. It will not serch again automatically unless you re-open it).

[mackz]

I have confirmed that the application actually is started, i am reopening and reconnecting each time after flashing the device but I still get no output I even tried to set the adress manually from the output that I got from the objdump.

[mackz]

This is what i get when i connect via JLinkRTTViewer:
LOG: Cortex-M: The connected J-Link (S/N 1050014356) uses an old firmware module: V1 (current is 2)
LOG: Cortex-M (ARMv8-M and later): The connected J-Link (S/N 1050014356) uses an old firmware module that does not handle I/D-cache correctly. Proper debugging functionality cannot be guaranteed if cache is enabled
LOG: FPUnit: 8 code (BP) slots and 0 literal slots
LOG: Security extension: implemented
LOG: Secure debug: enabled
LOG: CoreSight components:
LOG: ROMTbl[0] @ E00FF000
LOG: [0][0]: E000E000 CID B105900D PID 000BBD21 DEVARCH 47702A04 DEVTYPE 00 Cortex-M33
LOG: [0][1]: E0001000 CID B105900D PID 000BBD21 DEVARCH 47701A02 DEVTYPE 00 DWT
LOG: [0][2]: E0002000 CID B105900D PID 000BBD21 DEVARCH 47701A03 DEVTYPE 00 FPB
LOG: [0][3]: E0000000 CID B105900D PID 000BBD21 DEVARCH 47701A01 DEVTYPE 43 ITM
LOG: [0][5]: E0041000 CID B105900D PID 002BBD21 DEVARCH 47724A13 DEVTYPE 13 ETM
LOG: [0][6]: E0042000 CID B105900D PID 000BBD21 DEVARCH 47701A14 DEVTYPE 14 CSS600-CTI
LOG: RTT Viewer connected.

But i get no output.

I am using a nrf5340dk to communicate with the nrf9160.

[Einar Thorsrud]

I see. Can you dump the RAM of the device and search for the RTT buffer in it (see this post)? Do you find the magic string marking the start of the RTT buffer? Do you find only one instance or multiple? And does it work if you explicitly configure the RTT viewer to look in that address?

[mackz]

nrfjprog --memrd 0x20000000 --n 0x40000 > full_ram_dump.txt i ran this

and then used ctrl + F with "SE" and "RT" but could not find the magic string.