Inconsistent timeout in xSemaphoreTake

Kernel
1
  • Version : V10.3.1
  • Port : stm32l4

I have a weird behaviour with xSemaphoreTake and a binary semaphore. I call a function indefinitly and this function call xSemaphoreTake several times. Nothing give the semaphore so the function is use only like a delay (of course, this isn’t the goal of my code). The first call of xSemaphoreTake lead always to a fail in less than the timeout specified.

Here the function I call indefinitly :

int32_t Ad7124ReadDataWithIrq(Ad7124_TypeDef *dev, int8_t *data, uint8_t chCount){
	for(uint8_t i = 0; i< chCount;i++){

		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_SET);
               
               //if i == 0 => this function exit after less than 1ms (between 200 or 900µs)
		xSemaphoreTake(_BspExtAdcReadySemaphore, pdMS_TO_TICKS(1));

		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_8, GPIO_PIN_RESET);
                //This one is always good
		xSemaphoreTake(_BspExtAdcReadySemaphore, pdMS_TO_TICKS(1));
	}
	return(0);
}

I use GPIOC8 to measure the timeout with an oscilloscope.
I have only 1 task and no isr (only timer1 for tick). This bug occurs doesn’t matter chCount value.
If chCount = 1, the timeout is always 560µs.

Someone have an idea ?

2

Remember that a time-out value of 1 means until the next tick interrupt, which will normally be less than the tick period unless you know that a tick just occurred. That is the nature of ticks, they have a granularity of the period. If you want at least one tick period you need to wait for 2 ticks.

2 Likes
3

This is totally obvious, thank you for you time.