xEventGroupSetBits WatchDogIssue

I am facing a watchdog issue in my project, so I decided to debug it by reverting changes one by one. When I reverted the xEventGroupSetBits(dataStoreEvent, SleepSendDataFlag); line, the watchdog issue disappeared. What should I do next?

I am assuming your issue is something is preventing the watchdog from getting services before it times out and resets the system.

Please show the code snippet where the call to xEventGroupSetBits() is used.

else if((eventGroup == SystemWakeUpEventGroup) && (eventId == SfdackEvent))
	{
		UpdateTempCubeTailIndexValueInFlash();
		xEventGroupSetBits(dataStoreEvent, DataReceivedFlag);
		returnValue = true;
		/*Go to sleep when GetAvailableRecordCounts == 0 */
		if(dataRecordManager->GetAvailableRecordCounts == 0)
		{
			xTimerStop(dataReceiveTimer, 0);
			xEventGroupSetBits(dataStoreEvent, SleepSendDataFlag);
		}
	}
	else if((eventGroup == SystemWakeUpEventGroup) && (eventId == SdoneEvent))
	{

		/* need to update the head as successfully transmitted and continue to send the stored packets*/
		UpdateTempCubeHeadIndexValueInFlash();
/* Here is where i faced the watchdog issue*/
		xEventGroupSetBits(dataStoreEvent, DataReceivedFlag);
		returnValue = true;
		/*Go to sleep when GetAvailableRecordCounts == 0 */
		if(dataRecordManager->GetAvailableRecordCounts == 0)
		{
			xTimerStop(dataReceiveTimer, 0);
			xEventGroupSetBits(dataStoreEvent, SleepSendDataFlag);
		}
	}

Is the code really duplicated for both events SfdackEvent and SdoneEvent ?
When you put a breakpoint at the (2nd) xEventGroupSetBits call and make a single step is it normally executed or does it hang ? Or is the watchdog really about to expire because it’s just not updated in time by your application (because it’s too busy doing other heavy things like flash programming) ?

@hs2 .Yes both had the same flow except UpdateTempCubeHeadIndexValueInFlash() and UpdateTempCubeTailIndexValueInFlash(). I also tried with adding WatchdogTimerRefresh function before and after xEventGroupSetBits call but still had the same issue.

Hey there,
It sounds like the xEventGroupSetBits(dataStoreEvent, SleepSendDataFlag); line is triggering the watchdog issue in your project. Here are a few steps you can take to troubleshoot and resolve this issue:
Check Timing: Ensure this line isn’t causing long delays.
Task Priorities: Make sure the task setting the event and the task waiting on it have appropriate priorities.
Event Handling: Verify there are no deadlocks or frequent context switches involving the event group.
Watchdog Timer: Check the watchdog timer settings to ensure they are suitable for your tasks’ execution times.
Code Review: Look for any other related changes that might be affecting the watchdog.
Checking these areas, you should be able to pinpoint and resolve the issue.

One thing to look at is the code that is RECEIVING the Event Group message, as that might keep the system busy enough to miss the watchdog.

What can I do now , I had also tried with multiple watchdog timers before and after the xEventGroupSetBits(dataStoreEvent, SleepSendDataFlag); and also before creating the task.

This sound like a case where tracing can help. There is tracing support for the EventGroup functions so you can see when they are called and what the task scheduling looks like.
With a breakpoint at the watchdog reset it should be possible to save a “snapshot” trace.
One solution is to use our Tracealyzer tool that supports this, but there are of course alternative ways as well.

Thank you @johankraft ,I’ll try this.

I deleted the task before going to sleep now its working without watcdog.
is there anything i should do ?

Which task and did you delete and why? You have shared a minor piece of your code and just looking at that, it is not possible to say what is the correct solution for your problem.

In order to systematically debug your problem, you need to find out the reason why the watchdog is tripping. Look at the code which periodically pets the watchdog and try to find -

  • Whether it is not petting the watchdog because it determines that the application is stuck somewhere.
  • OR it is not getting a chance to run.

Once you know the reason of watchdog tripping, you’ll be able work out a solution.