Saturday, November 25th 2017, 10:34am UTC+1

You are not logged in.

  • Login
  • Register

Lupe

Beginner

Date of registration: Jul 19th 2017

Posts: 1

1

Wednesday, July 19th 2017, 3:16pm

OS_WD_Config(): How to configure pfTriggerFunc?

Hello,

I don't understand how to configure the new watchdog feature in embOS 4.34. From the docu:

Source code

1
void OS_WD_Config (voidRoutine* pfTriggerFunc,voidRoutine* pfResetFunc);


pfTriggerFunc Function pointer to hardware watchdog trigger callback function.



In the example, it's declared like this:


Source code

1
2
3
static void _TriggerWatchDog(void) {
WD_REG = TRIGGER_WD; // Trigger the hardware watchdog
}




Why/How should I trigger that "hardware watchdog"? If I have to trigger some watchdog here, /that/ one will reset the μC and pfResetFunc is meaningless...
Or what is meant by "trigger"? Is it to refresh another watchdog? But still, if that watchdog resets the μC, the embOS watchdog is surplus.


Could you help me out of my confusion, please?
I'd need it for an stm32f303...





SEGGER - Til

Super Moderator

Date of registration: Nov 14th 2007

Posts: 261

2

Wednesday, July 19th 2017, 3:50pm

Hi,

from the embOS manual:

Quoted

pfResetFunc may be used to perform additional operations inside a callback function
prior to the reset of the microcontroller.


The reset function is optional and gives the chance to react on such a situation.
You could e.g. write a message in a log file or set a piece of hardware in safe state before resetting the μC.

The basic idea is that one hardware watchdog is not enough for an RTOS with multiple tasks.
If you would trigger the hardware watchdog in one task only all other tasks are not checked and you don't know if they are still running.
Therefore we have the unlimited software watchdogs which you can use with the OS_WD_*() API.
In the end a hardware watchdog is used, of course.

I hope that makes it more clear.

Best regards,
Til

JLuc

Beginner

Date of registration: Oct 25th 2011

Posts: 7

3

Monday, October 23rd 2017, 9:40am

Hardware watchdog

Dear Til,

I don't understand your answer : "If you would
trigger the hardware watchdog in one task only all other tasks are not
checked and you don't know if they are still running."

Why Hardware watchdog reload in the idle loop is not possible ? Please explain .

In my mind, if any task is blocked, the idle loop is not reached anymore and the hardware watchdog is triggered.

What do you think about kicking the watchdog in the lowest priority task ?

Regards
Jluc

SEGGER - Til

Super Moderator

Date of registration: Nov 14th 2007

Posts: 261

4

Monday, October 23rd 2017, 9:52am

Dear JLuc,

Quoted

In my mind, if any task is blocked, the idle loop is not reached anymore and the hardware watchdog is triggered.

There could be situations where one task is not running as expected but OS_Idle() still gets executed.
Also triggering the watchdog in OS_Idle() only does not help because there could be a task which runs for a long time and therefore you don't reach OS_Idle() on time.
I guess you think of situations only where the CPU "stops" in a task and no further code gets executed.
In that case the hardware watchdog would be sufficient.
But you also want to check that all tasks are running as expected.

Quoted

What do you think about kicking the watchdog in the lowest priority task ?

Same here, with it you only know this task is still running but how do you want to know all other tasks are still running?

Best regards,
Til

JLuc

Beginner

Date of registration: Oct 25th 2011

Posts: 7

5

Monday, October 23rd 2017, 4:25pm

Dear Til,

thanks a lot for these interesting answers. If I'm correct, my watchdog in Idle loop is efficient for:
-> trapped in OS_Error(),
-> infinite loops without OS_Delay() consuming all the resource,

but not the task timing.

Gone to upgrade to 4.38... :thumbsup:
Jluc

SEGGER - Til

Super Moderator

Date of registration: Nov 14th 2007

Posts: 261

6

Monday, October 23rd 2017, 4:33pm

Quoted

If I'm correct, my watchdog in Idle loop is efficient for:
-> trapped in OS_Error(),
-> infinite loops without OS_Delay() consuming all the resource,

Yeah, that's it.

Usually you don't have the debug code and OS_Error() in your release firmware.
Although you can do so, of course!
But in that case you could also directly reset your microcontroller in OS_Error().