Notification not received after wake from low power

Kernel
21

Do you use xTaskNotifyWait() anywhere else in that task or any code it calls?

22

No. Since I’m new to this, I’ve been trying to keep it simple. Each task is as shown above - an endless loop with one call to xTaskNotifyWait(). The rest of the task code responds to notifications. Each task owns all it’s data (except the display buffer whose access is controlled with a semaphore) and all communication between tasks is either a notification or in one case a stream buffer and notification. The task that doesn’t get the notification uses only notifications.

23

When xTaskNotify() returns, do you handle all of the bits set in notifications before iterating in the forever loop? For example with a sequence of if statements, as opposed to a long if/else if/else if chain? Looking for something where you can accidentally consume the “notified” status without handling all of the notifications.

24

Yes, all are handled. The code looks like:

  if (notifications & AAA)
  {
  }

  if (notifications & BBB)
  {
  }

  if (notifications & CCC)
  {
  }

This particular task starts two timers for the two sensors. Each timer callback just calls:

	BaseType_t woken = 0;
	(void)xTaskNotifyFromISR(task, bits, eSetBits, &woken);
	portEND_SWITCHING_ISR(woken);

to read sensor measurements.

The other notifications are initialization (sent to task on startup and after wake) and sleep. The sleep process turns off power to the sensors and shuts down the I2C and SPI interfaces. it also stops the timers.

The initialization notification code always works on startup.

25

I discovered an error in my counting semaphore code and fixed it. What I see now is that sometimes the count is 1 as if something isn’t finishing a notification. I’ll have to look at it more. I want to believe this is a big clue.

Thanks for the suggestions everyone.

26

I think I finally (with everybody’s help) figured out what is going on.

The sensors task was getting a notification (not sure how) to measure one of the sensors after it was shut down. The SPI routines started the transfer and waited for the interrupt to release the semaphore which never happened. When I woke the processor the sensors task was still waiting for the semaphore and didn’t do anything else.

Things I did to remedy the situation:

  1. Used a counting semaphore such that any task not ready to enter deep sleep increments the semaphore count - the code only sleeps when the count is zero.
  2. Added a static variable in the sensors task that tracks whether or not the sensors are initialized. If not, the notification to read is thrown away.

Thanks again everyone for all the help.

27

Thanks for taking the time to report back.