This is cycling. However the test Hello world is working. I think there is a fallback to internal osc. I did a test with CumbeMX and there it works if you do the right clock config. There I had 10MHz as expected. It means that my hardware is OK. What I’m missing here?
Hmm… you might try comparing all of the RCC registers from the Mbed project vs the CubeMX project, to see what got set differently. Or you could try swapping out the system_clock.c file entirely and, if that works, swapping pieces between the Mbed and CubeMX versions until it works.
I have seen that if you zoom in on the scope there is a 10MHz added to the 300Hz that is fading out. It means that there is a stability issue with the oscillator. Maybe due to a missing setting? I will do the check as you propose.
Two other issues are:
1/ I use STM32CubeProgrammer with a ST-link2 clone with not working HW reset pin (as I can measure and read on the net). Sometimes the MCU is locking up and cannot connect anymore. If I move the USB cable to another PC (Linux) and do several times the following command I can erase the chip and unblock the lockup. Also, sometimes the reset line of the chip stays low for an unknown reason.
sam@elitebook-845:~/git/hmipanel$ sudo st-flash --connect-under-reset erase 0x08000000 0x100000
st-flash 1.7.0-352-g8c581c3
2024-01-08T18:57:22 WARN common.c: NRST is not connected
2024-01-08T18:57:22 ERROR common.c: Soft reset failed: error write to AIRCR
2024-01-08T18:57:22 INFO common.c: STM32U575_U585: 786 KiB SRAM, 1024 KiB flash in at least 8 KiB pages.
-> Flash page at 0x80fe000 erased (size: 0x2000)
Mass erase completed successfully.
2024-01-08T18:57:23 INFO common.c: NRST is not connected --> using software reset via AIRCR
2/ Putty is very sensitive to unexpected fall downs of the Tx pin or some deviating serial info. It happens ofthen that I can read the serial data on the scope but it is not appearing in Putty, even with the right serial settings.
1/ Issues with Putty. There was first an issue with a connector that was not aligned in the right way in the socket. That’s the danger if you use one row FTDI and a header with wide gap. Another thing is that the speed on the scope shows kbit/s which is misleading the same as the baudrate in Putty. If I measure 9.600 kbit/s (9600Hz or 104µs) it’s in Putty a baudrate of 9600 and not (9600 / 8) baud as you would expect. (Baud = symbols per second)
2/ Issues with lockup. I think that due to the oscillator issue the device is going in a lockup situation and the next programming cycle will be not valid (you have to ignore the programmed succesful message). In that case I reconnect and I do first a full erase before programming again. When the lockup in Windows is not recoverable I use the Linux pc. It’s a proof that there are some issues with the ST-Link clones. I ordered a real one and will put the clone away.
3/ The clock issue. I did a one by one line compare with working Cube-IDE code and came to a function that is almost exactly the same:
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK; // 160 MHz??? the devil
As soon as this line is in the code, the external oscillator begins to hiccup and the sine wave is not continue anymore. The 300kHz effect is due to the fact that the timebase of the scope is too low and you get an undersampling effect on the 10Mhz. If I stay on 200ns/div the hiccup is better visible. As soon as I remove this line the hiccup is done, but I think this is not right because the selector must be obviously on PLL. You can clearly see it in the Cube config :
I found the solution. The difference is that there is no while(1){} in my main. That’s the default if you generate a new mbed program. And a while(1) is the default at CubeIDE. When you exit the main function, the controller is waking up at a certain rate and is restarting the HSE with a transition effect at the piont you connect the HSE source to the SysClk (the devil line). Strange that the Xtal signal stays stable if you use another clock source.
In the system_clock.c there is a note:
* @note This function is called in mbed_sdk_init() function (targets/TARGET_STM/mbed_overrides.c)
* and after each deepsleep period in hal_deepsleep() (targets/TARGET_STM/sleep.c)
MBED_WEAK void SetSysClock(void) ...
My suggestion is to generate a Hello world demo program with a while loop after doing ‘mbed-tools new’.
The screenshot without a while loop. The Red data is the serial ‘Hello world’. The Oscillator runs during that period. (Yellow line) The sine wave is an undersampling effect. The envelope is the real 10Mhz signal that fades out when the main is finished and the controller sleeps. After a while there is a wake up and the HSE starts up again for a short time.