MCU-Link VCOM bitrate (1.5Mbps to 3Mbps range)?

[wj_ueos]

I'm replacing an older LPC-Link2 with the newer MCU-Link debug probe and I'm again trying to make use of the VCOM port. I could never get the LPC-Link2 to work at bitrates above 880kbps so I've never been able to make any use of it, but the MCU-link seems to behave properly at least up to 1.4Mbps, but above that it will no longer produce the correct bitrate.

I looked and couldn't find any newer firmware than the 1.098 which I'm using. Is the source code available for this (I assume it's based on the open DAPLink firmware)?

I have confirmed that the MCU-Link LPC55S69 UART itself (including the 74LVC1T45GW level shifter) runs fine well above the bitrate I'm trying to use (3Mbps), so this is a bug/misfeature somewhere in firmware-land. Note that it will happily accept a request for these bitrates, it just produces the wrong bitrate on the wire.

Any ideas how to proceed? It would _great_ to be able to retire the separate FT232H USB-to-UART adapter.

[radu_lazarescu]

You are not overclocking FC0 as the divide by 2 (FROHFDIV) is already configured in the firmware for other purposes, so that's why your patch works as it is. (I just mentioned it for reference)

Regrading the SWO bitrates, unfortunately that's the highest it can go: SWO is handled by a(nother) Flexcomm, the 48MHz FC clock divided by 9-cycles minimum bit length results in 5.33Mbps - which is matched (within 3%) to a target achievable rate of 5.45Mbps.

[wj_ueos]

Thanks again for the excellent explanation @radu_lazarescu !

I wasn't paying attention to the FROHFDIV setting when testing this out the other day (this is the first time I'm having hands-on experience with the Flexcomm hardware and the LPC55xx chips).

Is there a specific reason why there's a 9-cycle minimum bit length enforced (when the hardware is capable of going down to 5)? This seems to be true for both Flexcomms in this case. Even though reducing the minimum to 5 cycles it still won't quite reach the old LPC-Link2 speed it would be able to reach 9.6Mbps which is a lot closer. I'm not sure a simple patch would allow me to test this out as easily as the VCOM UART?

I'm getting quite a bit of overflow when running SWO Profile with the MCU-Link (at 5.454Mbps), something I'm not experiencing with the LPC-Link2 (at 9.75Mbps), which is why I'm interested in testing this out.

[radu_lazarescu]

The main concern with reducing the oversample rate is potentially more noise errors or incorrect data. Out of the 5 cycles, 3 are for data sampling, and since the oversample clock is running asynchronously from the input data, skew of the input data relative to the expected timing has little room for error.
We'll need to run some tests to check if it's feasible (considering also cable lengths, noise etc).
(I'm affraid this one is a slightly more complex patch to apply)

[wj_ueos]

That makes sense. As these cable lengths typically are reasonably short (in the 4-6" range) and with accurate enough xtal governed bitrates, reducing the oversampling ratio shouldn't be a major issue (on other hardware I'm regularly running a 3Mbps UART with only 4x oversampling without issues, not ideal by any means as there's no real bit "center" sampling position).

I totally understand if reduced oversampling ratio isn't something to enable by default, but I'm very interested to try this out if at all possible. Patching this kind of behavior might not be the simplest (as I'm not sure where the maximum bitrate calculation is happening). Someone is programming the trace divider within the target and that is capped to what the debug probe is capable of. I assume the debug probe isn't doing this on its own, it's up to the host to ask the debug probe what the maximum bitrate is, right?

[wj_ueos]

Close enough to 3Mbps measured between pin 2 and 3 on the target UART header on the MCU-Link

[wj_ueos]

I did some more investigation that involved debugging the MCU-Link with another MCU-Link just to see what's going on. Turns out that Flexcomm0 USART is clocked from the slow 12MHz clock, which means that the 5-cycle minimum bit length will result in 2.4Mbps. Apparently there are some other issues with the baud rate calculation, but interestingly enough manually changing the clock source to the 96MHz source _automatically_ scaled every baud rate setting correctly, so there's a very simple patch against the 1.098 binary which will select the 96MHz source instead of the 12MHz.

Patching 0x7045f44f (mov.w r0, 0x314) at address 0x9918 (which gets RAM-loaded at 0x20009390) to 0x4014f240 (movw r0, 0x414) is all it takes. This will select clock source #3 (FRO 96MHz) instead of clock source #2 (FRO 12MHz) in register FCCLKSEL0.

Not sure if there's a better place for MCU-Link-related questions in this forum?

[radu_lazarescu]

Hi @wj_ueos,

Yes, you're perfectly right. The Flexcomm0 used for VCOM is currently clocked from the 12MHz clock by the existing MCU-Link firmware. Additionally, a 9-cycle minimum bit length is enforced, which results in 1.33Mbps max achievable baudrate - matching your observations.
Anything higher than this requires FC0 to be clocked faster. FRO 96MHz is a good choice (divided by 2 in order to obey the 48MHz max Flexcomm clock).
If higher data rates are desired I can see no reason why we shouldn't include this change in a future MCU-Link firmware release. For the meantime your patch looks fine and allows a way forward to continue using MCU-Link.

Regards,
Radu

[wj_ueos]

Thanks for the explanation Radu!

With the 9 cycle minimum then it makes perfect sense why I ended up with around 1.3Mbps maximum bitrate.

I'm not sure if there's an automatic divide by 2 happening from the FRO 96MHz or if I actually overclock FC0 by patching the way I did. Having official support for higher bitrates would be great!

Speaking of higher bitrates, is there a similar limitation on SWO bitrates as I was running 9.75MHz SWO clock with the old LPC-Link2 but the MCU-Link only does 5.454Mbps (this is on a RT1062 target)? (see screenshots)