Hi.
We use DA14580 (Murata) as follows:
DA14580醒来从res延长睡眠模式ult of asynchronous event and starts non-connectable advertising process with timeout. If at the time of asynchronous event the previous advertising process is still ongoing, it will be canceled and new advertising with updated data will start.
So, in fact DA14580 wakes up from both asynchronous and synchronous events.
Generally it works, but sometimes DA14580 just stuck, doesn't produces synchronous events and doesn't respond to external events.
The interval between external events may be from few milliseconds up to minutes or hours.
It looks like there is a specific scenario that leads to the problem. DA14580 wakes up from asynchronous event, then from synchronous event and then stuck.
Again, usually it works.
When DA14580 is stuck the consumed current is about 500 micro Amperes.
Do you have some idea what is the reason and how to debug it?
Best Regards
Hi MichaO,
You will have to check where exactly the application stalls when that happens, try hook the debugger on the device when the application stalls, i suppose that the code ends up either in a hardfault_Handler or at an NMI_Handler (if you are using the watchdog). Check also if that occurs when sleep is enabled or not.
Thanks MT_dialog
I would like to clarify our problem:
1) System goes to sleep.( I'm pretty sure the MCU is sleeping.I use GPIO toggling to decide where the application is. I set it "High" in "arch_goto_sleep" function, just before "ext_wakeup_enable" and "Low" in "periph_init" just after "set_pad_functions" ).
2)Sometimes the system doesn't wake up neither from external event or from synchronous event (timer).
Regards
Hi MichaO,
I am not able to tell why this happens from the information that you provide, you will have to check where exactly the code stalls as mentioned above, what is the state of the code when the device is unresponsive. If you could measure the power consumption and when the device operates normally and falls to sleep the power consumption is close to 1.4uA and then the incident occurs and the power consumption is 500uA, then that means that code hits somekind of assertion (as mentioned above, hardfault, NMI, or a WARNING).
Thanks MT_dialog