Hello!

I've been working with the SEGGER_RTT suite for a while on our cortex-M4 without any problems, however I cannot get the same working on the M0 of our bluetooth module (DA14580).

In a little more detail:


The working setup on the M4
We use Eclipse IDE and work on Mac OSX, where we are able to load binaries, stop, start, add breakpoints etc. and inspect local/global variables and registers. In our (C++) code on the M4, one of the first calls in main() is SEGGER_SYSVIEW_Conf();. Later on, calls to functions like SEGGER_RTT_printf(0,"some formatstring"); occur. After loading the code with Eclipse the program JLinkRTTClient is able to identify that there is a GDB connection to the device and we receive output.

The problematic setup on the M0
On the bluetooth chip, it is possible to load the binary using Eclipse in the same way and inspection of variables also works. The JLinkRTTClient can again identify that there is a debug probe, and it reports the serial number of the attached probe. After that, JLinkRTTClient show no output.
The code base of the bluetooth module is written in C and the SYSVIEW library is not used. Therefor, the first call to the RTT library is SEGGER_Init(); and from inspection of the memory it seems that everything is perfectly fine. The address of the rtt control block can be found this way and coincides with the .map file of the build.

Tried fixes
Since the (Telnet?) JLinkRTTClient can connect to the jlink gdb server it seemed to us that the rtt control block could not be located so we tried to provide a hint to JLinkRTTClient by adding "monitor exec SetRTTSearchRanges 0x20000000 0x10000" to Eclipses settings "Debug Configurations > GDB SEGGER J-Link Debugging > myconf > Startup > Run/Restart Commands", knowing that the actual address is 0x20008004 and that its size is far less than 0x7ffc (= 0x10000 - 0x8004). This has no effect.
We also tried to initialise the memory of the control block to zero right before calling SEGGER_RTT_Init, because it seemed that the bss memory wasn't always zeroed on startup. This neither made a difference.

As a side note: the bluetooth module that we use has one-time-programmable flash memory, which on most of our devices has been used for other purpose (before we started to include segger rtt features).

Moreover, we also use the options:
"set mem inaccessible-by-default off" and
"set remote memory-read-packet-size 64" in Eclipses settings "Debug Configurations > GDB SEGGER J-Link Debugging > myconf > Debugger > GDB Client Setup > Commands"

Could anyone provide new ideas for troubleshooting, or (hint at) a possible solution?

Best!
Arend

A little update:

It seems that most of the issues are timing related, which may be related to the heavy use interrupts of the SPI module and bluetooth module of the chip.

• We reduced packet size of the debug probe with: "set remote memory-read-packet-size 16" in the debug configuration under "Debugger > GDB Client Setup > Commands".
• We reduced the number of down and up buffers to 1 each (with the define SEGGER_RTT_MAX_NUM_UP_BUFFERS)
  
• We reduced the size of the up buffer to 64 (using define BUFFER_SIZE_UP)
  
• We played around with the CPU speed setting for the SWO, finding that 16MHz works best, with SWO freq. set to 2MHZ.
  
• The RTTBuffer can now be found, perhaps the previous failure of this was because of executing the command "monitor exec SetRTTAddr 0x20008004" was executed before the chip was powered up?
  

Remaining issue:
When loading the code, and connecting to bluetooth first, and then starting JLinkRTTClient the chip now produces a bit of output.
When loading the code, starting JLinkRTTClient and then trying to connect to bluetooth, the system won't even succeed to advertise itself (making it impossible to connect).
This seems to be caused by the debug probe halting the system to copy the RTT control block. Is there any way to decrease this time even further, or another way to avoid the impact of the timing of the bluetooth communication?

Thanks for any help in advance!

Hi Niklas,

Its good to know that the cpu isn't halted. That probably means that we should be able to run
the RTT client properly while staying within the bluetooth timing requirements and setup/run a bluetooth connection.

The buffer setting is SEGGER_RTT_MODE_NO_BLOCK_SKIP.
The target interface speed is one that I assumed to be correct, but setting it to auto seems to increase it to 2000kHz. changing these seems to have no effect on the issue.
i.e. the GDB Server now outputs:


Target interface speed set to 1000 kHz
Select auto target interface speed (2000 kHz)


I've got a few debug scenarios that are reproducible, they indicate a direct relation between starting the RTTClient and the bluetooth connection crashing. An excerpt of the SEGGER_RTT_conf.h is added below too for convenience. Most settings have been tweaked with a conservative policy (small buffers etc.) hoping that an increase in speed would fix stuff, yet to no avail.

I would've never thought of that!
The instruction wfi is indeed used when putting the module into a deep sleep mode. I turned off all the occurences that I could find, but unfortunately the behaviour stays the same.
(Couldn't find any wfi instructions in the disassembly anymore)

Again thanks for the ideas.