STM32 Hal use floats to compute some HAL values (clocks, ...) but FPU HW unit is disabled on boot and it makes an hardfault.
STM32H743ZI2 Nucleo board
mbed studio 0.9.0 / Ozone debugger 3.20a / jlink probe driver 6.80
mbed-os-6.0.0 beta 1
mbed studio 0.9.0
set -O0 compiler optimizations
create an "empty" main
run program with Ozone debugger / jlink probe on a STM32H743ZI2 Nucleo board => hardfault
Hello,
STM32 Hal use floats to compute some HAL values (clocks, ...) but FPU HW unit is disabled on boot and it makes an hardfault. I temporary fixed it by adding SystemInit(); at the beginning of mbed_init() function
`void mbed_init(void)
{
=>
`void mbed_init(void)
{
SystemInit();
Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2689
Hi
FPU HW unit is disabled on boot
I don't understand this ?
Hello,
If you look in void SystemInit(void)
There is
/* FPU settings ------------------------------------------------------------*/
SCB->CPACR |= ((3UL << (10 * 2)) | (3UL << (11 * 2))); /* set CP10 and CP11 Full Access */
That's enable HW FPU if I'm not wrong.
SystemInit should already be being called well before mbed_init. It's basically the first thing that happens. See the boot sequence diagram here.
If it hadn't been called, I'm pretty sure you'd be seeing worse problems with non-initialised peripherals.
@fabiencomte Please use the issue template to describe the technical details for the issue. It helps us to understand the problem.
Look at the boot sequence in the documentation referenced above and compare it to what is happening on your hardware. If you find something is not executed, please provide details how to reproduce.
Hello,
Where is the Template please ?
The problem is quite simple, please search SystemInit function in mbed os sources, it's not called before main. Confirmed by a breakpoint with a jlink probe with ozone debugger.
As indicated by @kjbracey-arm
SystemInit is called here:
https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_STM/TARGET_STM32H7/TARGET_STM32H743xI/device/TOOLCHAIN_GCC_ARM/startup_stm32h743xx.S#L93
Hello,
Ok but if you set a breakpoint into it (using jlink probe with ozone debugger), you don't go in and you get a hardfault. Why ? Is the debugger use another entry point than Reset_Handler ?
Debuggers have a bunch of settings - there will usually be config choices about whether to stop on Reset_Handler and/or main.
If you can get the thing to stop at Reset_Handler, you should be able to step through and see what's happening.
@fabiencomte when you raise an issue the issue template is inserted automatically. All the fields in this template are required to be filled in. Please add this asap otherwise we may have to close this issue due to insufficient information to reproduce it correctly. Thanks.
Hello
@adbridge where is the template please ? Do I have to click something ?
Hello,
I found the Template and filled it. Sorry.
If you can get the thing to stop at Reset_Handler, you should be able to step through and see what's happening.
馃憤 Look at your debugger settings and see where it actually stops. This looks related to a debugger rather than any code issue.
I found the Template and filled it. Sorry.
Thanks for the update.
Hi @fabiencomte
Any update? Did you succeed to enter in SystemInit during system init...?
Hi
I think we can close the issue ?
Thx