Changing LSE clock setting between bootloader and application causing crashes

Custom and community boards
1

Hi,

In a product we are selling, we use an STM32F7 MCU that has both an LSE and HSE crystal. The type of LSE crystal that we have been using has been getting harder to find, but I realized that we don’t really need it for our application, so I want to stop populating it on the board so we don’t have to find it, and also save a little bit of money. The software for the MCU has a managed bootloader and an application. The problem arises with the bootloader, because the way it is now is that both the bootloader and application have the LSE available flag set to 1. To enable not populating the LSE, we would have to set that flag to 0 in both the bootloader and application. For programming new boards, that is fine because they are programmed at the same time. But when you try to use a bootloader and application that don’t have the same LSE available configuration, as would be the case with an update issued to a customer, the application crashes with the error “HAL_RCC_OscConfig ERROR”. My question now would be is there any way to stop a crash when a bootloader and application have differing clock settings like this? Or would we have to continue to populate the LSE crystal to maintain complete code compatibility? Thanks!

2

Hi

Note that LSE is mandatory in order to achieve better low power performance.

About crash in

I don’t understand yet how it can occurs…

Maybe if you don’t need low power, you could try to remove LPTICKER…?
“device_has_remove”: [
“LPTICKER”
],

3

That seems to work! Low power is not required, they are powered by the switched 12V line in a vehicle so power savings isn’t a concern. So does this mean that it now uses the LSI clock? Or does it use something else entirely?

4

After having set lse_available to 0,SW is using LSI.
When you remove LPTICKER, OS part of mbed-os is using only USTICKER, and never goes to deepsleep.