I have the same setup and issue as described in this topic.
The only difference - I use gcc-arm-none-eabi instead of SEGGER studio.
I performed small investigation and what I found:
gcc utilizes aggressive -Os optimization.
In this case symbol table looks in the following manner:
|00000000 l df *ABS*|00000000 SEGGER_RTT.c|
|---|---|
|0004a2b8 g F .application|00000068 SEGGER_RTT_WriteNoLock|
|0004a37c g F .application|0000000**4** SEGGER_RTT_Init|
|0004a320 g F .application|00000040 SEGGER_RTT_Write|
|0004a360 g F .application|0000001c SEGGER_RTT_WriteString|
|20017b60 g O .bss|00000108 _SEGGER_RTT|
And SEGGER_RTT_Init is:
0004a37c <SEGGER_RTT_Init>:
4a37c: f7ff bf6a b.w 4a254 <_DoInit>
mem32 0x20017B60 8 in JLink shows zeroes, which means wrong RTT initialization.
Changing optimization level to -O0 led to changing of code:
00056e26 <SEGGER_RTT_Init>:
56e26: b580 push {r7, lr}
56e28: af00 add r7, sp, #0
56e2a: f7ff fe5d bl 56ae8 <_DoInit>
56e2e: bf00 nop
56e30: bd80 pop {r7, pc}
and after that address 0x20017B60 contains signature “SEGGER RTT” or
53 45 47 47 45 52 20 52 54 54 00
I suspect, that listed above related not only gcc but any other compiler with it own rules of optimization.
And…
It is not and of the story.
I still see nothing in the RTTViewer, meanwhile correct output present in the RTT buffer.
Investigation of NRF_LOG_ALLOW_OVERFLOW is the next step.