Proper way to share peripherals between bootloader and UserApp in SBSFU. STM32WB CPU2 getting stuck.

[MBuen.1]

Hello guys, how are you?

Currently i have an interesting problem happening with my STM32WB5M. I have a project that uses SBSFU alongside with a firmware that uses the BLE peripheral with CPU2 and etc. I don't use the BLE loader, i developed i customize USB loader.

The only peripheral that is shared between bootloader and my user app are 3 GPIOS that i use for a RGB led. The thing is, when i share this resource, sometimes CPU2 get stuck in my main firmware and it doesn't initialize. I need my WDT to kick in and reset the firmware, then CPU2 initializes. The only way things work smooth is when i have my debug connected to the board (i tought this very very weird).

If i remove the GPIO from my bootloader, everything works fine with or without my debug probe. I think the CPU2 behaviour on STM32WB5M very strange. CPU2 get stuck sometimes because of a problem that is not even related to it.

Any suggestion about what this could be? Is there something relevant that i should do to "share" this GPIO's between bootloader and main firmware? Anyone would have a hint about why the CPU2 get stuck for somethings that it doesn't have anything to do with it?

Regards,

Matheus

[Fred]

Hello,

can you indicate the 3 GPIOs you are using and how they are configured:

• in the context of SBSU
• in the context of your USB loader

The point is that there is no real concurrency right ?

If the 3 GPIOs are used by SBSFU and your firmware then SBSFU is not running any more when your firmware is active.

So, unless these GPIOs are used for security purpose like a tamper I guess you may reconfigure it in your application.

Or are you referring to the SECBOOT_USE_STANDALONE_LOADER ?

Could you please share more details ?

Thanks & Regards

[MBuen.1]

Hello Fred,

I am using a Standalone loader, that is the usb loader i developed. I have no problems with it. My problem actually is when my main firmware gets executed and sometimes CPU2 gets stuck and doesn't properly initialize. I'm using pins A9, A10 and A11. These pins are for an RGB led. During bootloader initialization they're set as GPIO output to perform white color in the RGB. In my main firmware they're used as PWM pins, so that i'm able to perform fading in my RGB led. Removing the A9, A10 and A11 from the SBSFU solved the problem of CPU2 getting stuck in my main firmware, weird isn't? I completely got it that there is no concurrency since both images are not executed at the same time.

But it'is weird, everytime i have something a little off in my applicattion CPU2 suffers as collateral damage and simply decides not to work properly. It happened before in some others situations and i was able to find the problem and solve it.

I'm really trying to understand what is happening behind the scenes in CPU2 so that i can corretcly manage these interactions.

[Fred]

I asked my colleagues working on GPIO and there is no special sequence to respect to do this reconfiguration.

How is the clock configuration manage din your case?

What is the exact symptom of this CPU2 getting stuck ? Is it in a deadlock state ?

[MBuen.1]

I know that CPU2 is fully initialized when the static void APPE_SysEvtReadyProcessing( void * pPayload ) function reachs to the stack. If this condition (p_sys_ready_event->sysevt_ready_rsp == WIRELESS_FW_RUNNING) is met, i know CPU2 is good to go. My firmware keeps waiting until CPU2 is fully initialized to start it's other routines that are dependent of bluetooth and other shared resources with CPU2. What happens is that this function is not called when my CPU2 is stuck.

And this happened another time aswell. I had a problem with my watchdog. I was refreshing a watchdog without initializing it. Until i found the problem, CPU2 didn't initialized correctly. It failed to initialized like 3 times in a row, then after reseting and trying again, a couple tries later it would init (this is the same behaviour i'm experiencing right now). It was quite unstable. After i solved this watchdog problem, the CPU2 started to work fine.

Another weird thing is, if i have my STLink debug connected in my board and also hooked up at the PC (even without debug session, just powered up), these CPU2 problems doesn't happen to me, everything goes fine. If i unhook STLink, then problems begin.

About the clock configuration, the code initialization would be fine or would you rather a printscreen of the clock three on CubeMX?

[Fred]

Clock tree can be interesting.

Another thing also : are you sure the GPIOs are clocked when reconfiguring them ?

I mean : are you sure that when the GPIOs are used by SBSFU, then they are not de-initialized when leaving SBSFU ?

Then, if you try to reconfigure them before they are clocked then the configuration is not applied.

I'm not saying this is the problem, I'm just pointing out a possible cause.

[MBuen.1]

I was deinitalizing them when leaving SBSFU. I remove that and it actually solved the whole problem hehehe.

Thank you very much for the suggestion!

But honestly, when something is wrong, why this reflects in the CPU2? Any idea?

[Fred]

I am really not a WB expert but I think that it is possible to output on GPIOs most of the real time activity of CPU2.

Is it possible that there is a GPIO collision between this debug activity and your RGB led GPIOs ?

I do not know if this might cause issues on CPU2 side, just wondering.

[Remy ISSALYS]

Hello,

When CPU2 is stuck, can you read the memory at 0x20030000 in order to see if CPU2 is in Hardfault or not ? If the value at this address is 0x1170FD0F, CPU2 is in Hardfault and if it's the case can you have a look to flash registers ?

Best Regards

[MBuen.1]

Hello Remy,

Indeed this is the value of that register when CPU2 is stuck, so this indicates that in this context a hardfault occurs in CP2. Could you point me out to which flash registers would be interesting for me to investigate?

Regards,

Matheus

[Remy ISSALYS]

Hello,

It would be interesting to look Flash memory status register (FLASH_SR).

Best Regards,

[MBuen.1]

HI @Remy ISSALYS​ 

I know its been a long time but i'm facing this issue again. Its not relating to the GPIO sharing but my CPU2 is actually hardfaulting again and i would like to know why.

I debugged some FLASH Flags and here's what i have:

FLASH_FLAG_MISERR: 0

FLASH_FLAG_PGSERR: 1 (Is 1 with or without hardfault)

FLASH_FLAG_PGAERR: 1 (Is 1 with or without hardfault)

FLASH_FLAG_SIZERR: 0

FLASH_FLAG_FASTERR: 0

FLASH_FLAG_OPTNV: 0

FLASH_FLAG_RDERR: 0

FLASH_FLAG_OPTVERR: 0

FLASH_FLAG_BSY: 0

FLASH_FLAG_CFGBSY: 1 (When hardfault) 0 (when CPU2 boots normal)

FLASH_FLAG_WRPERR: 0

FLASH_FLAG_PROGERR: 0

FLASH_FLAG_OPERR: 0

FLASH_FLAG_EOP: 0

FLASH_FLAG_PESD: 0

FLASH_FLAG_ECCC: 0

FLASH_FLAG_ECCD: 0

A weird behavior is that if i add a static variable of 4 bytes during compilation, it changes binary size and these CPU2 hardfaults stop happening. Even with that 4 bytes adding to the binary and no more CPU2 hardfaulting happening, both FLASH_FLAG_PGSERR and FLASH_FLAG_PGAERR are still in 1.

Could you give me any hint?

Regards, Matheus