jeromecoutant
commented
2 months ago Hi
Both the SetSysClock_PLL_HSE() and SetSysClock_PLL_HSI() just return 0, with even the command //TODO
Yes... but functions are "weak", so you can define them in your application!
Description of defect
Hello all, For my project I have a STM32U575ZI MCU with an external crystal that oscillates at 24MHz. Naturally, I wanted to set this in both custom_targets.json
"overrides": { "clock_source": "USE_PLL_HSE_XTAL" },"config" : { "hse_value": { "macro_name": "HSE_VALUE", "value": "24000000" } },as well as the PLL values in the system_clock.c file for the internal clock, located originally in _mbed-os\targets\TARGET_STM\TARGET_STM32U5\TARGETSTM32U575xI However, only the SetSysClock_PLL_MSI() function is implemented, while I need the SetSysClock_PLL_HSE(). [see image below] Both the SetSysClock_PLL_HSE() and SetSysClock_PLL_HSI() just return 0, with even the command //TODOThis is probably just overlooked. For now I can test already some things with the internal clock. However, don't think it will be good enough for the CANbus communication.
Target(s) affected by this defect ?
STM32U585xI, STM32U575xI, STM32U575xG
Toolchain(s) (name and version) displaying this defect ?
N/A
What version of Mbed-os are you using (tag or sha) ?
mbed-os6.17.0 (https://github.com/ARMmbed/mbed-os/releases/tag/mbed-os-6.17.0) However, I see the issue is still present in the master branch.
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
N/A
How is this defect reproduced ?
One can reproduce this defect, by compiling for either of the STM32U5 MCU's while setting the internal clock to follow the HSI or external crystal HSE.