Need M0+ recovery solution without reseting M4

[OrnellaBenzi]

Hi! We are developing a sensitive device using the STM32WB55, using in the M0+ the concurrent Thread+Ble binary (we use the concurrent because we'll need both Ble and Thread in the near future, althought the most important role is the Thread communication, and is the only one we are using right now). 
Thread works fine, but after some hours on the field (not in lab), the M0+ gets stuck in some state where it no longer ack the commands from our app in M4. Reseting the whole device makes it functional again, but it is not an opcion in the field. We need a way of reseting the M0+ without touching the M4, in order to make it function again. 
The state in which the M0 wont respond is simply it wont ack any command anymore after a while. It is not consistent, it could happen after 4h or after 12h. It is not reproductible in the lab, it only happens on the field. So we need to implement a recovery for when it happens. 
Please any hint is welcome. 

 

[Uwe Bonnes]

Did you try via the SCB_AIRCR register?

SCB_AIRCR = SCB_AIRCR_VECTKEY | SCB_AIRCR_SYSRESETREQ;

[OrnellaBenzi]

Hi @Uwe Bonnes , thanks for the fast response. Is there a way to use the SCB_AIRCR register for resetting ONLY the M0+ while the application in the M4 keeps running? 
We use SCB_AIRCR = SCB_AIRCR_VECTKEY | SCB_AIRCR_SYSRESETREQ; for reseting the whole system, but it is not acceptable for us to recover that way beacuse de application in the M4 cannot reset whenever the M0+ thread stack get stuck

[Uwe Bonnes]

Sorry, I assumed there is a SCB for each CPU.

[OrnellaBenzi]

@Uwe Bonnes  I think the M0+ actually has its own SCB_AIRCR, but it is not accessible from the M4.

[_Joe_]

Hi,

It is not possible to reset the M0+ core independently from the M4 core in the STM32WB55. All reset sources will reset the complete system, including both the CM4 and CM0+ cores.

So you need to find the root cause of the M0 not responding.

Which version of CubeFW are you using?

Do you have more information about the context/use case? 

About the sequence in which the problem occurs?

 

Have you already checled if the M0+ core is in a hard fault ? can you check if the SRAM2A contains the hard fault keyword 0x1170FD0F? more information in the AN5289.

BR, Joé

[OrnellaBenzi]

Hi @_Joe_ thank you for the response.

The device that is showing such behaviour is intalled in field, and we couldn't reproduce this failure in the lab, so we are trying to include in the periodic backend reports as much information as possible. We will add the SRAM2A value in order to know if it is a hardfault or other fault type.
But my question remains, if it is in fact a hardfault or similar, how could we recover the M0+ from it? Without resetting the whole system. Isn't a wdg/command/register we could use to restart the M0+ stack??

We are not using CubeFW, we use our own firmware based in libopenCM3 and we have only exported from CubeFW the Middleware/STM32_WPAN and the Application/STM32_WPAN and adapt them to work with FreeRTOS and LibopenCM3. 

We start both BLE and Thread, and right now we only use Thread to communicate with a stm32wb55 dongle (this one does use CubeFW v1.22.0). We send a 76bytes packet over CoAp Post every 2secs aproximately, and receive the response. This should work, but after some hours (sometimes 4hs, sometimes 12hs, again only on field) it stops, the M0+ no longer acks commands. We put guard to only send new CoAp Posts if the previous has timeouted or responded correctly. 

As soon as we catch the fail, I will post the values obtained from the report of SRAM2A.

[Uwe Bonnes]

You can put code in the hardfault handler to restore the devices you use to default values. Then set stack and jump to reset handler/startup code of the M0

[OrnellaBenzi]

Hi @Uwe Bonnes,
I understand how to recover from a HardFault in general, but in the case of the M0+ of the STM32WB55, I have no access to the HardFault handler nor to its registers.
The firmware running on the M0+ is a proprietary wireless stack provided by ST, delivered as a precompiled binary. From the application side (running on the M4), the M0+ behaves as a black box — I can only communicate with it through the IPCC and SHCI/TL layers.
That’s why I’m looking for a workaround to recover from this kind of fault without reseting the whole system (M4 included): I have no control over what the M0+ does internally, nor can I handle its exceptions directly.

[OrnellaBenzi]

Hi @Christophe Arnal , thank you for your response. The binary we are using is stm32wb5x_BLE_Thread_dynamic_fw.bin (version 1.21.0) 

I will add to the log the values you suggested and update when the issue arises again with as much information as possible about the problem.

Regards

[RiceCorn]

Hi,

I got similar problem with v1.21.0 stm32wb5x_Zigbee_FFD_fw.bin stack. M0 not ack to M4 API after communicating for few hours.

We found out that its wont happen with v1.22.0 stack. And its based on the wireless activity "send packet".

Maybe the wireless environment on the field is much more complicated than in the lab in your case?

We're still working on v1.21.0 stack (got other issue with v1.22.0 stack), and try to reduce wireless activity to avoid issue.

Hope to see any solution here.

[Christophe Arnal]

Hello,

The first 32bits value 0x1170FD0F reports the CM0+ is in its HardFault interrupt handler. You can find a short description on this in AN5289 rev18 Chapter 4.8.2.

As long as the CM0+ is in Hardfault, there is no way to send any kind of command to CM0+. As I already reported, it is not possible by HW Architecture to reset only CM0+.

I strongly doubt there is a way to find any king of workaround on CM4 side to avoid CM0+ getting into such HardFault.

I am currently checking with the team if this HardFault is already known and in that case, what would be the first CM0+ Wireless version where it has been fixed.

It is almost sure you will have to upgrade CM0+ wireless firmware. Obviously, if this is possible, upgrading to latest version is always the best.

Regards.