Standby Mode Control to minimize power consumption (STM32L476RCT)

[Dongjin]

My name is Lee Dongjin from South Korea and I am developing the system below.

While developing a "Multi-Point Correlation Leak Detection System" using your company's MPU (STM32L476RCT), the following problem occurred 

and I would like to ask for a solution.

System operation is as follows.

- It is a correlation type water leak detection equipment that collects water leak sounds through a high-sensitivity sensor, detects water pipe leak points, and analyzes the collected data using a correlation algorithm to express the results.

This equipment is capable of multiple water leaks and extensive exploration by operating 8 Logger Pod sensors simultaneously.

Eight Logger Pods exchange commands and data through IR infrared communication with the SuitCase in the Carry Box.
SuitCase is a structure that exchanges commands and data with PC Applications through RS232 serial communication.

In standby mode, the 8 Logger Pods are in sleep mode and wake up when they receive a communication request from the PC application.

Afterward, the eight PODs perform synchronization between Logger Pods, Configure setup for recording water leakage sounds,

record water leakage sounds, and process data.

Also, when requested by the PC, data upload and download are executed, and if there are no other commands or executions,

it must automatically enter sleep mode after 5 seconds.

The object is to minimize power consumption by the logger pod and maximize battery life. The pod must be in the sleep mode all the time except when it needs to power up circuits during the following events.

1. Recording data
2. Communication between pod and suitcase.

Recording data
It is assumed that it can take XX seconds to set up the gains on the Analogue circuit and be ready to log data.
At regular intervals, the logger will read RTC and check if it is time to start a new recording session. Once RTC reaches the time to start recording, it will power up the sensor and analog circuits, adjust the gain, and be ready to start recording data at the exact start time of recording.
The logger will record data for the configured duration. It will then switch off power to the sensor and analog circuits and go back to sleep ready for the next recording or any comms wake-up.
 
Communication between pod and suitcase.
Upon receiving a comms character from the suitcase electronics or PC the logger wakes up and starts checking for any valid communications commands.
If a valid command is received by the logger, it will service that command and remain awake for a timeout period 5 seconds to look out for any further commands. If no further command is received during the timeout period of 5 seconds the logger will go back to sleep mode.
 
Typical commands from suitcase to logger will be Uploading Recording configuration  etc. or Downloading data from logger pods.
There are no commands to instruct the logger to go to sleep. It goes to sleep by itself,

The system must go to Sleep mode in 5 seconds after the command is performed, wake-up with other commands to run the command, and then go to Sleep mode if there is no other command in 5 seconds. 

At this time, there should be no problems with the loss, synchronization of the data, but it does not solve the Sleep problem as shown below.

[Why the Sleep Mode function is not fully implemented in the current system] The MCU for POD currently used is the STM32L476RCT series Ultra Low Power MCU. The cause of the problem is that ST's low-power MCU does not support the performance of RTC and low-power counter as well as PIC. According to the specifications provided by ST, it emphasizes significantly superior power consumption compared to PIC, but it is found that it is not possible to turn on RTC and operate Low Power Count and General Counter like in PIC as in the firmware to be applied to actual POD. It's possible. To solve this, many work-arounds were implemented and tested, but in the end, the problem caused by the unstable RTC Tick Count (32.768kHz) and the limitations of the protocol that could compensate for this reached a point where it could not be overcome. Work Around, which I had tried so far, did not use the RTC inside ST's MCU because it was unstable. Instead, I designed a separate external RTC (MCP7940MI) and tried to use it in synchronization with it, but I still measured the tick count (32.768kHz) using a counter. It must be specified in the protocol and sent to the suitcase and PC, but we eventually discovered a phenomenon where the PC-side protocol ignores the raw data. Tick ​​Count is measured when a synchronization signal is received and Recode is completed and Download (Reading) is started. It is understood that if the two Tick Counts are outside a certain range, the PC ignores them.

Please suggest a solution to the above problem.

I look forward to your help.

[TDK]

> the problem caused by the unstable RTC Tick Count (32.768kHz)

If the LSE crystal is unstable, perhaps re-examine the circuitry around this. Try different load capacitors, or a different crystal. Perhaps copy the design and parts used on an ST board.