Cannot see both bootloader and application RTT output

[giansta]

When attaching the SEGGER J-Link RTT Viewer to a nRF52 based target, in most cases only the logs from application are visible and not the logs from MCUboot, more seldom only logs from MCUboot.

Expected behaviour: both logs from MCUboot and from application are expected to be visible, like using serial or SWO.

Found solution:
The issue is due to the fact that the viewer or debugger looks in the target memory for RTT control block and buffer, searching for the "SEGGER RTT" signature. As MCUboot and application have them at different addresses, it either finds one or the other. The solution would be having them at same address for both and avoiding the application to re-initialize them if already initialized by MCUboot.
Confirmation and fixing hints can be found i.e. in https://devzone.nordicsemi.com/f/nordic-q-a/30310/easy-way-to-merge-bootloader-and-application-rtt-output
In the Nordic SDK this patch works well.

In Zephyr CONFIG_SEGGER_RTT_SECTION_DTCM defines a different section (.dtcm_data) for RTT control block and buffer, yet it seems that:

• The linker file doesn't support this config and a orphan section .dtcm_data warning is given by the linker;
• The SEGGER_RTT.c module needs patches to initialize properly the variables in `.dtcm_data' section and to not initialize them if already done by MCUboot.

I could verify that the two fixing above solve the issue and both logs are finally visible.
I didn't find any other open issue or PR mentioning it. I'll propose new PRs for the above changes, unless a better solution exists.

Impact: difficult to debug and diagnose proprietary DFU.

Environment:

• OS: Windows 10 (Linux will be tested soon)
• Toolchain: zephyr-sdk-0.14.2
• commit 8e4137f

[giansta]

#53569 and zephyrproject-rtos/segger#17 should fix the issue.

[m-wichmann]

Tested with both patches manually applied on nRF Connect SDK v2.0.2 and works as expected. Would be great to see in a release.

Not relevant for me, but I think this could be a regression for some users. If both CONFIG_SEGGER_RTT_SECTION_DTCM and the device tree option zephyr,dtcm are selected, then the symbols __dtcm_start and __dtcm_end are defined multiple times and the symbols from dtcm_data are added twice in the linker script. To me this looks like CONFIG_SEGGER_RTT_SECTION_DTCM was intended to be used to place the RTT data in the DTCM (Data Tightly-Coupled Memory; never seen an MCU that had this) and only be used if zephyr,dtcm is chosen. Maybe it would be better if there would be a new section and a new option like CONFIG_SEGGER_RTT_SECTION_STATIC that is only used for sharing RTT between application and bootloader. But I could be wrong on all of this (again: I'm not affected).

[giansta]

Thank you for your comment.
Indeed I totally agree that the CONFIG_SEGGER_RTT_SECTION_DTCM usage for RTT is misleading. I've tried now to add an option to the choice SEGGER_RTT_SECTION named SEGGER_RTT_SECTION_FIXED_ADDR and use it for the SEGGER case.
I left even the CONFIG_SEGGER_RTT_SECTION_DTCM case that keeps defining SEGGER_RTT_SECTION as ".dtcm_data". I don't know if this really makes sense, as I also never used a MCU that has DTCM. I can just try with my nRF52 target.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[giansta]

Hi, I would like to remove the stale label for this issue.
The two PRs that should resolve it were reviewed, but there's still a doubt about how to synchronize this change with possible new updates by Segger.
As 'm not able to identify Segger contributors here, I tried right now to open a ticket in Segger support.
Whatever other help is welcome.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[MarcianoPreciado]

Any luck?

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[jhedberg]

@giansta I'll assume the issue has been fixed. Feel free to reopen if necessary.

[giansta]

@giansta I'll assume the issue has been fixed. Feel free to reopen if necessary.
The two related PRs (#53569 and segger #17) progressed, but not yet merged.
I'd like to reopen this, yet I don't seem to have the rights.

[giansta]

@giansta I'll assume the issue has been fixed. Feel free to reopen if necessary.

Hi @jhedberg
In my opinion this issue should be open till the two related PRs (#53569 and segger #17) are open.
I don't find how to reopen it, it looks like I cannot.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[cfriedt]

Still seeing this. I suspected that the buffers were in different locations for mcuboot and the app.

2 years old already. I mean, there are older bugs 🤷🏼‍♂️

[cfriedt]

This bug affects stm, or really any device that uses a JLink. Given that there is a possible fix for it, it would be nice to get it in soon-ish.