Using LPTIMTick in a Low-Power Tracking Application

[saiida-debbiche]

Hello Jeff,
I’m working on a low-power tracking application (STM32 + FreeRTOS).
The tracking device periodically acquires environmental sensor data and transmits it once per cycle (cycle configurable to 5, 15, or 60 minutes).
Within each cycle, sensors are read at a fixed reading period derived from the configured sampling rate (e.g., reading period = 300000ms or 900000ms or 3600000).

In software, a 1 ms software timer checks when the reading period is reached, pushes a message into a queue, and a task processes the reading and data handling.

To reduce power consumption between readings, I have integrated your LPTIMTick library with configUSE_TICKLESS_IDLE = 2.

I’d like to confirm I’m using it correctly:

Entering low-power mode
Do I need to explicitly do anything to enter STOP1/STOP2, or will FreeRTOS automatically call vPortSuppressTicksAndSleep() (and therefore your configPRE/POST_SLEEP_PROCESSING hooks → vUlpPre/PostSleepProcessing) whenever no tasks are ready?
Waking up at the right time
Who exactly sets LPTIM1->CMP for the next wake-up?
Is it vPortSuppressTicksAndSleep() that calculates the required counts and sets CMP so the MCU wakes just before the next expected deadline (software timer expiry, task delay, etc.)?
In other words, is the wake-up time computed automatically by LPTIMTick from the FreeRTOS tick count, or do I need to manually configure LPTIM’s period?
Interaction with my timers
In my design, the software timer triggers sensor reading (via the queue).
Does LPTIMTick guarantee that wake-up happens in time to run the callback exactly at the expected deadline (without noticeable drift)?
GPIO analog mode during sleep
In an other project, I have reduced current draw further by reconfiguring all GPIOs as analog inputs in configPRE_SLEEP_PROCESSING and restoring them in configPOST_SLEEP_PROCESSING.
Would you recommend doing this here as well with LPTIMTick? If yes, should I perform the GPIO reconfiguration inside your vUlpPreSleepProcessing() / vUlpPostSleepProcessing() hooks?
This my supervisor task :

void ReadFromSensorTimerCallback(void const * argument)
{
	/* USER CODE BEGIN ReadFromSensorCallback */
	CounterForReadingTimeout++;
	if ((CounterForReadingTimeout % UserSystemSettings.GlobalReadingPeriod)==0){
		//PowerPathControl(Sensors_pwr_Line, true);
		InitSensorsAfterReset(&sensorMap);
		osMessagePut(SensorQueueHandle, READ_ALL_DATA, 0);
	}
	if((CounterForReadingTimeout % UserSystemSettings.savingPeriod)==0){
		osMessagePut(SensorQueueHandle, SAVE_SYSTEM_STATUS_TO_EEPROM, 1);
	}
	/* USER CODE END ReadFromSensorCallback */
}
void StartSystemSupervisorTask(void const * argument)
{
	/* USER CODE BEGIN StartSystemSupervisor */
	/* Infinite loop */
	uint8_t counter;
	osEvent msgFromQueue;
	SDQueueMsg_t tosdMsg={.CSVLogId=PeriodicSensorLog};
	osMutexWait(TasksMutexHandle,portMAX_DELAY);
	InitSystemSettings(&UserSystemSettings);
	MessageBufferCreate(ApplicationEventSDCard,&ApplicationEventMessageBuffer,&ApplicationEventMessageBufferStruct);
	MessageBufferCreate(ApplicationEvent,&ApplicationEventSDCardMessageBuffer,&ApplicationEventSDCardMessageBufferStruct);
	InitSensors(&sensorMap);
	SaveLoadCellularPaths(&ApiComEndpoints,SIM7600_CELLULAR_PARAMS_START_ADDRESS,Load);
	InitInaSettings();
	CalibrateAllINA216();
	ActivateGPS();
	InitFetchMesurementForSensors(&UserSystemSettings);
	ComputeReadingPeriod(&UserSystemSettings);
	InitliveData(&GlobaleLiveData);
	StartStopTimerAccordingToPeriod(ReadFromSensorTimerHandle, 1);
	GetSystemStatusBeforeReset();
	SaveLoadGPSPosition(&GpsOutput, GPS_POSITION_START_ADDRESS, Load);
	LoadTLE();
	HAL_UART_Receive_IT(&huart4, (uint8_t*) &Uart4xMsg, 1);
	StartStopTimerAccordingToPeriod(WakeupTimerHandle, UserSystemSettings.TransmissionIntervalMs);
	osMutexRelease(TasksMutexHandle);
	for(;;)
	{
		msgFromQueue = osMessageGet(SensorQueueHandle,portMAX_DELAY);
		if(msgFromQueue.status <= osEventTimeout)
		{
			if (msgFromQueue.value.v == SAVE_SYSTEM_STATUS_TO_EEPROM)
			{
				SaveLoadSystemStatus((LiveData_t*)&GlobaleLiveData,SYSTEM_STATUS_START_ADDRESS, Save);
			}
			if (msgFromQueue.value.v == SAVE_SENSOR_STATUS_TO_EEPROM)
			{

				for(counter = 0; counter < MAX_SENSORS; counter++)
				{
					SaveLoadSensorStatus((SensorStatus_t*)&GlobaleLiveData.sensorStatus[counter], counter,SENSORS_STATUS_START_ADDRESS ,Save);
				}
			}

			if (msgFromQueue.value.v == READ_ALL_DATA)
			{
				for (uint8_t i = 0; i < MAX_SENSORS; i++)
				{
					TreatSensorMesurement((SensorSettings_t*)&UserSystemSettings.sensorConfig[i], (SensorStatus_t*)&GlobaleLiveData.sensorStatus[i]);
					SensorAlarmeLedController();

					if(i == MAX_17048_BATTERY_GAUGE_LEVEL_INDEX)
						checkBatteryPercent(GlobaleLiveData.sensorStatus[i].lastValue);
				}
				osMessagePut(SensorQueueHandle, SAVE_SENSOR_STATUS_TO_EEPROM, 1);

			}
		}
		osDelay(1);
	}
	/* USER CODE END StartSystemSupervisor */
}

I would really appreciate your help on this, and I’d be very grateful for your feedback. Thank you!

[jefftenney]

Entering low-power mode and waking up at the right time

When you configure FreeRTOS for tickless idle, the FreeRTOS scheduler automatically induces tickless sleep when conditions permit. You don't have to do anything. The scheduler calls vPortSuppressTicksAndSleep(). The implementation of vPortSuppressTicksAndSleep() implements both the sleep and the scheduled wakeup at the end of the sleep period. So code in lptimTick.c automatically calculates and sets wakeup times (using the CMP register).

But with the code you posted, the scheduler will never induce tickless sleep because the conditions for tickless sleep never exist. If a task will be ready to execute in <= 1 OS tick, then the scheduler simply executes the idle loop until the task is ready to execute.

Interaction with my timers

Yes, software timers work properly with lptimTick.c. Timing is as accurate as LPTIM's reference clock.

GPIO analog mode during sleep

No I don't recommend changing GPIO configs in the pre/post sleep routine. Any changes to GPIO config related to sleep should be controlled by the same application software module that normally controls them. Those software modules should be written to keep their GPIO signals in the most quiescent state possible at all times unless they are actively being used. And when they are actively being used, if the pre-sleep function happens to run, it will select normal sleep instead of deep sleep because it sees that the application is not currently ready for deep sleep.

[saiida-debbiche]

In my case, I’m not trying to build my own software timers, I'm already using a FreeRTOS osTimer (1ms period) to increment a counter and check whether the configured GlobalReadingPeriod or savingPeriod has elapsed. When either condition is met, the timer callback posts a message to a queue, and my SystemSupervisor task processes sensor readings or saves system status.
I was just asking if the issue of tickless sleep never being met comes from the 1ms periodic timer that keeps a task ready almost constantly, which prevents expectedIdleTime from growing beyond 1 tick and stops vPortSuppressTicksAndSleep() from running ?

void ReadFromSensorTimerCallback(void const * argument)
{
	/* USER CODE BEGIN ReadFromSensorCallback */
	CounterForReadingTimeout++;
	if ((CounterForReadingTimeout % UserSystemSettings.GlobalReadingPeriod)==0){
		//PowerPathControl(Sensors_pwr_Line, true);
		InitSensorsAfterReset(&sensorMap);
		osMessagePut(SensorQueueHandle, READ_ALL_DATA, 0);
	}
	if((CounterForReadingTimeout % UserSystemSettings.savingPeriod)==0){
		osMessagePut(SensorQueueHandle, SAVE_SYSTEM_STATUS_TO_EEPROM, 1);
	}
	/* USER CODE END ReadFromSensorCallback */
}

If that’s the case, what would be the alternative?

[Olstyle]

So effectively you ARE building SW Timers out of a SW Timer with those counters.
Just use one OS timer per sensor with the actual reading timeout as period instead of your own counters
https://www.freertos.org/Documentation/02-Kernel/02-Kernel-features/05-Software-timers/01-Software-timers

[saiida-debbiche]

I understand your point, but in my case I have around 35 sensors in the application. Using a separate FreeRTOS software timer for each sensor would significantly increase RAM usage and add overhead in managing so many timers.
That’s why I opted for a single 1 ms periodic software timer that drives a central scheduling mechanism

[Olstyle]

I have the distinct impression you have never used an embedded OS. Scheduling and timing ARE what FreeRTOS is for and it solves that incredibly efficiently. Building your own scheduler on top of a FreeRTOS timer or task does NOT make any sense and is the base problem of why you broke the power management. For example Timers are just a struct in a queue. Really not much more than your counters. But solved in a way that they can be scheduled efficiently.

[jefftenney]

To add some support to @Olstyle, from a strategy perspective, it's best to tie scheduling overhead to the scheduled operations themselves. The operations have a natural associated cost in power consumption, so a good design adds the cost of scheduling to the cost of the operation. This is a fundamental design principle of low-power systems.

In your case, you want the act of reading a sensor to be tied to scheduling the next one. Asking FreeRTOS to set a timer is the scheduling overhead. That's better than your custom scheduler because yours ties the scheduling overhead to the waiting itself.

You should probably end up with what @Olstyle is suggesting, separate FreeRTOS timers for each sensor. Or maybe grouping the sensors by sampling rate. Whatever fits your application.

You could post on the FreeRTOS forum for tips. There is a lot of experience there.