UART interface programming speed

[shortnr]

Hello all,

I'd like to know if there is a set of acceptable UART baud rates for CLI use (CubeProgrammer CLI defaults to 115200 baud for UART).

Looking at the GUI for CubeProgrammer, after selecting UART, it shows that a baud of 460800 or 921600 is possible, but only a baud of 460800 worked with the CLI, but 921600 timed out (I think.. the window closes very fast, as we're 'calling' the CLI from within a Python script).

Any help would be appreciated. 460k baud is still much faster than the default, but if I can push the limits with 921k, I'd be happier :)

Thanks!

[Tesla DeLorean]

The ROM based System Loader auto-bauds on a 0x7F 8E1 pattern, technically it measures the pattern with a timer and converts that to a BRR setting for your chip / clock.

Most RS232 level shifters have an bandwidth below 1 Mbaud, and most USB-to-CMOS Serial adapters should be able to do 460800 or 921600. Real problem is the protocol really isn't robust or standard. With your own loader or staged process you could use X or Y-Modem effectively, and stand-alone terminal tools.

Many STM32 support a USB DFU method too.

[TDK]

115200 is the highest rate tested, see AN3155. Past that, it will depend on the clock accuracy/mismatch between the STM32 and the host system.

https://www.st.com/resource/en/application_note/an3155-usart-protocol-used-in-the-stm32-bootloader-stmicroelectronics.pdf

[Tesla DeLorean]

The OP is inarticulate to the specific STM32 involved.

Something that resolves cleanly into the MCU clock used by the loader, based off HSI or MSI, and perhaps PLL, might be the optimal choice.

For ones own boards, with known function / performance, a crystal based clock, and code staged into RAM, could undoubtedly go a lot faster.

Part of the reason ST auto-bauds is that it's got NFI what the users will actually build, and the loader tries to bring no external dependencies to the problem. The USB and CAN loaders do expect crystal oscillators for the most part, but somewhat over the map as to supported values and ranges.

[AScha.3]

just to compare : i tried download speed (usb-> vcp->uart) on arduino 2 .

max. rate without errors, reliable, is 460k.   so stay with this, i would recommend. :)

or invest many hours of try and work, to get it 3 seconds faster ....