I have been working on a project for the last 12 months using STM32F091RC. Now there is a huge shortage of F091’s I am trying to switch over to STM32L073RZ. Both supported by mbed, almost identical pin-out, some code changes, but should be relatively straightforward. Put the L073 on my board and it does not run.
In order to rule out my hardware then switched to a Nucleo L073. On a standard L073 Nucleo the code runs. The only difference I can see between my board and the Nucleo is the clocking. My board has a 8MHz crystal (but on my old code the F091 actually runs from the internal oscillator), the Nucleo has a 32kHz oscillator and MCO from the ST-LINK.
Running a very basic blink program (slight adapation of the mbed example code) and I want to run the L073 from the internal 16MHz oscillator and also remove the 32kHz xtal
If I remove SB50 (disconnect MCO) the code runs fine - I assume here it is falling back to HSI.
If I remove R34 and R36 to disconnect the LSE xtal (but with MCO from the ST-LINK still connected), the the program fails to run and LD2 blinks in a repeated pattern - 4x on/off fast, then 4x on/off slow (which is nothing to do with my code).
So after further reading I have a better understanding of the clock tree. I see that the 32kHz oscillator is not used as a source for system clock. I am baffled by how removing R34 and R36 can affect the running of the code, especially as if I look at 32kHz xtal on a scope it doesn’t seem to even be oscillating.
After a deeper search of the forums I have discovered that clock settings can be overridden through an mbed_app.json file. I will give this a go, however it seems like it should not be necessary and the board should already be running from HSI16 if I remove the MCO jumpers from the STLINK
I get the following terminal output:
++ MbedOS Error Info ++
Error Status: 0x80FF0100 Code: 256 Module: 255
Error Message: Fatal Run-time error
Error Value: 0x0
Current Thread: Id: 0x0 Entry: 0x8000215 StackSize: 0x0 StackMem: 0x0 SP: 0x20004E7C
For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=NUCLEO_L073RZ
– MbedOS Error Info –
I also get the following warning in the compiler (not every time)
Warning: ‘IS_LPTIM_CLOCK_SOURCE’ macro redefined [-Wmacro-redefined] in “extras/mbed-os.lib/targets/TARGET_STM/TARGET_STM32L0/device/stm32l0xx_ll_lptim.c”, Line: 64, Col: 9
Warning: ‘IS_LPTIM_CLOCK_PRESCALER’ macro redefined [-Wmacro-redefined] in “extras/mbed-os.lib/targets/TARGET_STM/TARGET_STM32L0/device/stm32l0xx_ll_lptim.c”, Line: 67, Col: 9
Warning: ‘IS_LPTIM_OUTPUT_POLARITY’ macro redefined [-Wmacro-redefined] in “extras/mbed-os.lib/targets/TARGET_STM/TARGET_STM32L0/device/stm32l0xx_ll_lptim.c”, Line: 79, Col: 9
All (almost) STM platforms are clocked using either:
8Mhz HSE crystal
8Mhz MCO feed from the ST-link MCU
Internal RC clock (I don’t use that so cant remember the frequency)
Using OS6.6 I believe the normal start up is auto detect HSE first then fall back on the other sources, so if you fit the 8Mhz Xtal and capacitors, change the links as detailed in the the Nucleo 64 board manual then it ‘should’ start on the HSE external Xtal.
At least It does for me.
Crystal and capacitors are critical for stable cold start up, use the part numbers as in the BOM list.
I normally get these parts from Mouser.
Before you could force it by putting this in your mbed_app.json “target_overrides”.
You can also check with a scope using a high impendence probe directly on the Xtal if it is working.
The 32Khz Xtal is used for accurate RTC timing not system clock.
thanks for your reply. Yes after reading up I have realised my error - the 32kHz crystal is not used for system clock, to avoid confusion I have corrected my original post to reflect this. My issue is that I want to run without the 32kHz crystal fitted, but if I remove R34 and R36 mbed os seems to crash. This is on a standard NUCLEO-L073 board with the official mbed os blinky example. The same code compiled for the NUCLEO-F091 works fine,
For anyone with the same issue, have found that it can be resolved by creating an mbed_app.json file in your source directory with the following code:
Hmm, that should auto detect, maybe not.
Most of the early STM Necleo 64 boards did not have any Xtals fitted.
However here are some more target_overides settings that may be relevant for you, I use for low power on the ‘L’ series.
"target.clock_source": "USE_PLL_HSE_XTAL", // clearly only if you fit it!
But I think now some of these settings are redundant in the latest OS.