Wednesday, November 22nd 2017, 6:18am UTC+1

You are not logged in.

  • Login
  • Register

Reply

Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Message information
Message
Settings
Automatically converts internet addresses into links by adding [url] and [/url] around them.
Smiley code in your message such as :) is automatically displayed as image.
You can use BBCode to format your message, if this option is enabled.
Security measure

Please enter the letters that are shown in the picture below (without spaces, and upper or lower case can be used).

The last 6 posts

Monday, October 23rd 2017, 4:33pm

by SEGGER - Til

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().

Monday, October 23rd 2017, 4:25pm

by JLuc

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

Monday, October 23rd 2017, 9:52am

by SEGGER - Til

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

Monday, October 23rd 2017, 9:40am

by JLuc

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

Wednesday, July 19th 2017, 3:50pm

by SEGGER - Til

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

Wednesday, July 19th 2017, 3:16pm

by Lupe

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...