STM32WB55 CPU2 HardFault for unknown reason.

MBuen.1 · ‎2023-01-18

Hey guys, how are you?

It's been a long time that i'm facing a issue with STM32WB CPU2, most of the times i just fix it without really knowing the cause of it.

Basically what happens is after power-up CPU2 simply won't initialize on the first try. I have a loop on my main application waiting for CPU2 to boot. Since it doesn't boot, my WDT kicks, microcontroller gets reseted and then in this second try CPU2 initialize properly. I debugged CPU2 fault register and accused a hard-fault in CPU2, that i'm not very sure what can be.

The weirder of all of this is that small changes on my firmware compiled binary stop this problem. Last time this occurred, (after a ton of researching and some trial and error) i had to add a static char array of 4 bytes. This changed the .bin size and the problem simply disappeared. If i added a static variable that didn't change the .bin size (due to binary padding during compilation), the problem still happened.

I compared the generated binaries files in both of this occasions (with and without this static variable) and i saw some differences that i'm not sure what are exactly in the first 800 positions of the binaries. I tough that such small change wouldn't make a big difference like that in the binary. Here's the difference that i saw. The one on the left is the binary that CPU2 works fine.

This application i develop it has a SBSFU Bootloader that can (or not) be attached to it. Another weird thing is that if I generate the sbsfu + application binary file (using the application binary file that CPU2 hard faults, demonstrated in the image above), everything works smooth and CPU2 DOESN'T HARD FAULT. The supposed part of the firmware that i'm showing in the image above is also changed in this SBSFU + App binary, as shown in the picture below. I expected that this SBSFU + App binary would be just an attachment from both bootloader and application binary, but still it changed a part of what supposedly is my application. Probably this changes are due some bootloader handlings that application has when is compiled for SBSFU usage, such as self-test, vector table and etc. But i still tough that this wouldn't change this first positions of the application.

I'm sorry for the long text, i'm investigating this problem for months.. all the time this occur to me i just fix it without really knowing why (sometimes deliveries are more important than causes :confounded_face: ). When this happens, i just rollback the changes on my code and try it to rewrite on a different manner, looking for some code mistake that the compiler didn't catch it, i don't know.

That is my whole problem.. one quick question that you guys can aswer me is, aren't this first positions the ISR Vector table? Why the heck a small change would impact this part of the binary?

If you guys could give me at least some hint on how to solve this CPU2 problem.

Regards,

Matheus

Remy ISSALYS · ‎2023-01-31

Hello,

Can you check the value FLASH_SR register when you jump on your app from your bootloader?

Best Regards

MBuen.1 · ‎2023-01-31

I'm not using bootloader nor any SBSFU application alongisde with my firmware. The problem happens when i have just my firmware application running.

Remy ISSALYS · ‎2023-02-01

Hello,

In your application there is something that causes flash error before CPU2 initialization. To find which instruction generate the fault, you can add breakpoint on each initialization function and check FLASH_SR register.

Best Regards

YWor.1 · ‎2023-02-07

Hello.

I encountered the same issue as mentioned.

What causes the problem in my situation is some cube init functions, to be more precise if I call MX_TIM1_Init(), CPU2 is not starting and flash status register SFGBSY bit stays set. If I don't call MX_TIM1_Init() it all works fine, CPU2 finishes its startup routine and sends asynch event and flash status register SFGBSY bit is resets.

I have no idea about the binary size, I just found that after TIM1 initialization the flash CFGBSY stays set so I figure out that it might be the problem.

SRAM2a values that identifies a hardfault issue are:

0x20030000: 1170FD0F 00006E44

0x20030008: 00006A93 20037A90

Hope that information can help with find the real problem.

Thanks.

Arno1 · ‎2023-02-10

Hi Matheus,

Have you been able to solve your issue?

I don't have the same problem but for posterity's sake I'm interested in what caused the issue and how you solved it.

Regards, Arno