USC RPL noticed another bug: on STM32H7, if you set the LPUART to run at higher than 9600 baud, data is not transmitted (& presumably received) correctly. @qwertyquerty noticed that when he set 115200 baud, he was actually getting 960 baud! I suspect that noone noticed this before because LPUART is more commonly used at lower baudrates, but it's actually better than the regular UART peripherals (it has a FIFO though Mbed currently does not enable the FIFO), so no reason not to use it at higher baudrates too.
Digging into it a bit, it looks like what happens is, the serial_api.c code checks the baudrate, and if it's too low to run off the LSE oscillator, it falls back to the next configured clock source. By default, on STM32H7, that is PLL2. However, we don't actually use PLL2 in code, so I don't even think it was getting enabled (frankly I'm not sure how data was getting transmitted at all, at any baud).
This PR fixes it so that on STM32H7, only LSE, HSI, and SYSCLK are selected as clock sources for LPUART as these are the clock sources that actually work! It also cleans up and documents the way that this option works.
Impact of changes
STM32H7 processors can now use LPUART at baudrates above 9600
Undocumented SYSCLK fallback for LPUART clock source is now documented
Improved documentation for target.lpuart_clock_source option
LPUART clock code does not try to use LSE oscillator if LSE oscillator does not exist
Migration actions required
Documentation
Updated docs in targets.json5
Pull request type
[] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[X] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)
Test results
[] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR
Summary of changes
USC RPL noticed another bug: on STM32H7, if you set the LPUART to run at higher than 9600 baud, data is not transmitted (& presumably received) correctly. @qwertyquerty noticed that when he set 115200 baud, he was actually getting 960 baud! I suspect that noone noticed this before because LPUART is more commonly used at lower baudrates, but it's actually better than the regular UART peripherals (it has a FIFO though Mbed currently does not enable the FIFO), so no reason not to use it at higher baudrates too.
Digging into it a bit, it looks like what happens is, the serial_api.c code checks the baudrate, and if it's too low to run off the LSE oscillator, it falls back to the next configured clock source. By default, on STM32H7, that is PLL2. However, we don't actually use PLL2 in code, so I don't even think it was getting enabled (frankly I'm not sure how data was getting transmitted at all, at any baud).
This PR fixes it so that on STM32H7, only LSE, HSI, and SYSCLK are selected as clock sources for LPUART as these are the clock sources that actually work! It also cleans up and documents the way that this option works.
Impact of changes
target.lpuart_clock_sourceoptionMigration actions required
Documentation
Updated docs in targets.json5
Pull request type
Test results
Reviewers