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.

[Christophe Arnal]

Hello,

Unfortunately, there is no way to reset only CM0+ core. Full device reset is enforced by the Hardware System Architecture and there is no way to avoid/bypass this.

So, the only solution left is to investigate the issue and fix it.

Since you need to improve your log, please make sure to dump all 4x  32bits values from SRAM2A base address. ( The meaning of these values are described in AN5289 - Chapter 4.8.2 SRAM2).

Could you please provide the exact version and binary name of the CM0+ Wireless Firmware you are using ? We mandatory need to know the exact version to correlate with the values read from SRAM2 in case this is reported as an hardfault.

Regards.