RTT not updating when single stepping

[ddowling]

I have been experimenting with the RTT support in BMP as it looks perfect for fast logging output. However there seems to be an issue with how the polling for rtt IO is performed when stepping through code with gdb.

Currently poll_rtt() is only called in main.c:60 when the while loop has gdb_target_running true. It breaks out of this loop when gdb_target_running goes false before calling the poll_rtt() function. Then the application is blocked waiting for new packets in the gdb_getpacket() and there is no RTT polling performed.

blackmagic/src/main.c

Lines 44 to 64 in 309a17c

	static void bmp_poll_loop(void)
	{
	SET_IDLE_STATE(false);
	while (gdb_target_running && cur_target) {
	gdb_poll_target();
	// Check again, as `gdb_poll_target()` may
	// alter these variables.
	if (!gdb_target_running || !cur_target)
	break;
	char c = gdb_if_getchar_to(0);
	if (c == '\x03' || c == '\x04')
	target_halt_request(cur_target);
	platform_pace_poll();
	#ifdef ENABLE_RTT
	if (rtt_enabled)
	poll_rtt(cur_target);
	#endif
	}
	SET_IDLE_STATE(true);

I think this can be fixed by ensuring poll_rtt() is called on exit from this loop. I can work a up patch and pull request if this will help.

[ALTracer]

how the polling for rtt IO is performed when stepping through code with gdb.

1. BMP provides the fastest line-stepping user experience among debuggers I've tried, thanks to its in-firmware gdbserver implementation which has no delays between RSP FSM parser and ADIv5/DP bitbanger. With some GDB memory map adjustments (make Flash regions cacheable so that GDB doesn't repeatedly request parts of .text referenced by stack pointer just so it can perform a stack backtrace unwind) BMP+GDB can step (on the order of) 10 times a second, comparable to keyboard keypress held repeat rate. Of course, assuming a high enough SWCLK frequency and no middleware like BMDA or probe-rs.
2. Any bugreports involving RTT have the complication of not having a reliable MVP to reproduce bugs -- there are testbenches for Semihosting and for SWO now in an org-owned repo. So what are you using this on (Zephyr, NuttX, plain RTT sources)? What target chip and debugger platform? Instruction-stepping (DHCSR C_STEP manipulation) or line-stepping (hardware breakpoint on some forward instruction + continue)?
3. Why do you want it that way, are you debugging a homebrew RTT implementation, or just line-stepping across multiple RTT_WriteString() statements? If you recommend BMP performs RTT controlblock polling more often than every target_halt_poll(), how will that also interact with "RTT enabled but no cblock detected yet" time span? (with rtt disabled it's not a problem, with rtt enabled and some cblock discovered the polling should be relatively tame, 24-byte read and 4N byte read depending on channel count, then possibly upchannel buffer readout)

[ddowling]

It has been a while since I looked at this but I was using the RTT_WriteString statements to debug an application on a STM32F103 microcontroller. I agree that the BMP firmware is a fast GDB server implementation and I use it a fair bit. I was experimenting with logging in RTT_WriteString and I noticed it was delayed in the output of log statements when I was using "next" to step through functions.