SWO timing accuracy against target device

I have created a driver for the SAM3U2C on the DAPLINK firmware and am testing it with an nRF52840 module to ensure that it is working properly and although I can get SWO data from the module, there seems to be a timing issue and there's loads of framing errors that the SAM3U2C device gets, the majority of the output is OK but it does have parts that are corrupted or just end abruptly or have issues (I'm comparing to what a JLink can capture on the same SAM3U2C host chipset and that has no issues). I've been running the UART at 1Mbps for this testing (the sample app on the nRF52840 is a zephyr app from zephyr - the philosophers one which has been configured with SWO log backend output and built with -DENABLE_SWO) whilst the JLink seems to be running the UART at 2Mbps. Are there any suggestions for how to investigate or debug this issue further? I think it's probably related to the cortex pre-scaler value as I have attached a logic analyser to the SWO line and can also see framing errors in that output occasionally. Perhaps it's related to the accuracy of the debug clock as the JLink software does an automatic speed test for the connected module in order to determine the speed it is running at (it's not exactly 64MHz) which doesn't seem to be supported in pyocd.

No source file or test is identified. Start by tracing pyOCD's SWO and UART timing configuration for the SAM3U2C, then compare its prescaler and debug-clock assumptions with the nRF52840 logic-analyser output and JLink's 2 Mbps capture; done means identifying and reproducing the framing-error cause or documenting the missing clock-speed support.