Re: hal watchdog

I also worry (slightly) that the default time between sanity waking up and the watchdog firing may not be enough. It is configurable so that is all good, but maybe the default should be a bit longer as sanity is checked in the idle task and if a system has lots of tasks the idle task may not ru

Re: hal watchdog

Well, I have worked on systems where 200 or even 500 msecs would definitely have caused the code to crash. For example, you have to do lots of crypto processing and you dont have HW support. That being said, I think this is a moot point as it is configurable so all good. I just like to hear mys

Re: hal watchdog

Oh yeah, sorry. I dont know why I said 200 when it is clearly 500 :-) Thanks for pointing that out. All good about the msec v sec thing. > On Sep 23, 2016, at 11:02 AM, Sterling Hughes wrote: > > 2 reasons: > > - most (all) chips provide that granularity that i’ve seen, so why not? IMO, >

Re: hal watchdog

2 reasons: - most (all) chips provide that granularity that i’ve seen, so why not? IMO, it’s not up for us to decide what people set watchdog interval to in the HAL if it’s portable. - as you point out, it’s convenient to have a consistent timebase between sanity and watchdog, given how i’v

Re: hal watchdog

Why is the interval defined in milliseconds btw? Is there a particular reason for it? Is it because you wanted to be able to separate the sanity interval and the watchdog interval by less than one second? Or are you worried that some watchdogs may have very small timeouts and milliseconds would

Re: hal watchdog

Hey — A follow up on this, I’ve committed initial support for the Nordic platforms for the watchdog, along with modifying this API a bit. I made the watchdog expiry a millisecond value (in hal_watchdog_init()), as pretty much every watchdog I’ve seen executes in millisecond resolution. I re

Re: hal watchdog

> On Aug 30, 2016, at 12:59 PM, Mathew Calmer wrote: > > On August 30, 2016 at 12:28:50 PM, will sanfilippo > (wi...@runtime.io) wrote: > Sounds reasonable. As I am sure you know, doing it through the sanity task > sometimes is an issue getting the time right as you wo

Re: hal watchdog

On August 30, 2016 at 10:51:47 AM, marko kiiskila (ma...@runtime.io) wrote: Hi Mathew, > On Aug 29, 2016, at 5:02 PM, Mathew Calmer > wrote: > > It’s implied but not made explicit that hal_watchdog_init sets up a > re-occuring wat

Re: hal watchdog

On August 30, 2016 at 12:28:50 PM, will sanfilippo (wi...@runtime.io) wrote: Sounds reasonable. As I am sure you know, doing it through the sanity task sometimes is an issue getting the time right as you would then need to know the worst-case timing of all the tasks that

Re: hal watchdog

Hi, 2) When developers create the system and want a HW watchdog, what in the OS tickles the watchdog? Is that done by the sanity task or is it done by the OS in some other manner (os time tick, for example)? Or does the creator of the application need to provide for the tickle? This would be

Re: hal watchdog

Sounds reasonable. As I am sure you know, doing it through the sanity task sometimes is an issue getting the time right as you would then need to know the worst-case timing of all the tasks that could be running… but any way you cut it, you have to put some time limit on that… in past lives I ha

Re: hal watchdog

> On Aug 29, 2016, at 5:04 PM, Sterling Hughes wrote: > > Should we have init(), enable(), disable() and tickle()? I imagine there are > places you are going to want to disable the watchdog and re-enable it, but > not reprogram how long the expiry should be? > Sure. I can add enable() for s

Re: hal watchdog

Hi Mathew, > On Aug 29, 2016, at 5:02 PM, Mathew Calmer wrote: > > It’s implied but not made explicit that hal_watchdog_init sets up a > re-occuring watchdog, not a one time use one (who wants a one time use > watchdog….). This should be made explicit though. > right. I can change the wordi

Re: hal watchdog

Hi Will, > On Aug 29, 2016, at 4:53 PM, will sanfilippo wrote: > > I have some questions: > > 1) What happens if the internal watchdog does not allow for a long timeout? I was thinking of just returning an error from init in that case, but maybe we need a routine that returns the max supporte

Re: hal watchdog

Should we have init(), enable(), disable() and tickle()? I imagine there are places you are going to want to disable the watchdog and re-enable it, but not reprogram how long the expiry should be? sterling On 29 Aug 2016, at 16:40, marko kiiskila wrote: Hi, I was going to add support for h

Re: hal watchdog

It’s implied but not made explicit that hal_watchdog_init sets up a re-occuring watchdog, not a one time use one (who wants a one time use watchdog….). This should be made explicit though. Also, it would be nice if the watchdog module could tell you if a recent reset was caused by the watchdog

Re: hal watchdog

I have some questions: 1) What happens if the internal watchdog does not allow for a long timeout? 2) When developers create the system and want a HW watchdog, what in the OS tickles the watchdog? Is that done by the sanity task or is it done by the OS in some other manner (os time tick, for ex