RTT output hangs the BMP when not read by host

[adamcbraun]

There seems to be a problem with RTT when the host is not reading the data out.

I have a target image that is running RTT and generates a fair amount of output. If I am running a monitor program on the RTT serial port, the output works well and there is no problem. Additionally if I do not enable RTT in the BMP, there is no problem. However, in the case where RTT is enabled but not being read on the host system, the BMP firmware hangs and becomes unresponsive.

This issues is caused because the first UART packet is loaded into the USB endpoint buffer and the buffer is never taken by the host. When the next rtt polling occurs, the rtt data is read but the rtt_write function gets stuck in the while loop attempting to write the packet to the endpoint buffer. As the buffer has not been (and likely won't be) consumed by the host, this loop can never succeed and the device is hung. Further, because the BMP is stuck in this loop, it is unable to service the requests required to open the rtt serial port leaving the only recovery method to be a BMP power cycle.

[koendv]

Does this patch solve the problem?
patch.txt

A more general solution would be to append the output of usb serial, traceswo decode, rtt, and redirect_stdout to a single circular buffer, and use the usb tx interrupt to trigger usb writes.

[ALTracer]

I faced this exact problem while testing RTT yesterday on three platforms.
@koendv your patch assumes 3ms... why? BMF has used 100Hz SysTick timebase, so it will time out after 10ms minimum. Maybe you're using RTT on some out-of tree platform with a more precise platform_time_ms() timebase?

I agree with unifiying the four data sources into a single sink queue. Is it possible to simultaneously redirect aux_serial, traceswo, rtt and semihosting stdout to the second CDC-ACM interface? Will it keep the order (of events happening, time-wise)?

[koendv]

You're right. You can use 10ms, and it will give the same result on BMF. Like this?
patch.txt

Is it possible to simultaneously redirect aux_serial, traceswo, rtt and semihosting stdout to the second CDC-ACM interface?

Yes. But now this results in four different usb packets to be sent, even if everything would fit in a single packet.

Will it keep the order (of events happening, time-wise)?

There seems to be some code in aux_serial.c that does just that:

• implements a transmit fifo, therefore keeps order.
• uses USBUSART_DMA_TX_IRQ.

I think this would be an improvement: avoid polling. transmit less packets, but fuller packets if multiple data sources are used. Also only transmit a 0 byte packet if transmit fifo is empty and last packet was 64-byte.
But I'm not sure what the planning is?

koen

[dragonmux]

Given things like RTT currently cause hangs if the aux serial port is not being monitored on the host, this would be a very interesting approach to us to see explored so if you'd like to explore it, and it does result in improvements in speed, or usability, etc, then we'd very much welcome a PR for it.