cancel
Showing results for 
Search instead for 
Did you mean: 

Need M0+ recovery solution without reseting M4

OrnellaBenzi
Associate III

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. 

 

13 REPLIES 13

External chips like BlueNRG have a reset pin. Strange to omit such a function in the embedded software.

OrnellaBenzi
Associate III

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

OrnellaBenzi_0-1760547942406.png

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

Hi,

BlueNRG is a Single Core Device.

Similarly to STM32WB55, the reset acts on the full device.

 

Regards.

RiceCorn
Associate

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.