Currently when the SWO buffer fills up, and swo_buffer_bytes_available reaches SWO_BUFFER_SIZE, the buffer management code will fail to cap the availability count. This results in the implementation sending the same buffer of data multiple times to the host till the transfer amount has been satisfied.
This is not correct, and requires the management code to detect this over-filling and advance the read index appropriately while capping the availability count. This will prevent us sending garbage.
Note that there are actually two approaches needed - if the data excess is from the Manchester decoder then the extra bytes should be thrown away and an artificial overflow inserted into the buffer, meanwhile if the extra bytes are from the UART decoder, then DMA requires we do the read index tracking change instead. In this latter case, we will get a glitch in SWO data output that we cannot prevent and we cannot easily mark the overflow. The only way to work around this would be to suspend DMA till the overflow condition is cleared, including setting up the extra overflow marker, before resuming DMA This is doable but more complicated.
Currently when the SWO buffer fills up, and [`swo_buffer_bytes_available`](https://github.com/blackmagic-debug/blackmagic/blob/362d736c2f30bb04f9b21e1ea941e0fb3dbd944b/src/platforms/common/stm32/swo.c#L61) reaches `SWO_BUFFER_SIZE`, the buffer management code will fail to cap the availability count. This results in the implementation sending the same buffer of data multiple times to the host till the transfer amount has been satisfied.
This is not correct, and requires the management code to detect this over-filling and advance the read index appropriately while capping the availability count. This will prevent us sending garbage.
Note that there are actually two approaches needed - if the data excess is from the Manchester decoder then the extra bytes should be thrown away and an artificial overflow inserted into the buffer, meanwhile if the extra bytes are from the UART decoder, then DMA requires we do the read index tracking change instead. In this latter case, we will get a glitch in SWO data output that we cannot prevent and we cannot easily mark the overflow. The only way to work around this would be to suspend DMA till the overflow condition is cleared, including setting up the extra overflow marker, before resuming DMA This is doable but more complicated.