Dealing with WDT in an Atmega 324PB

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again,

I need a WDT to work. A simple one. It need to reset the uP if the software get stuck somewhere. I have Googled for examples but it is rather hard to se what I need. Many examples uses Irq. I think I don't need that.

 

 

I think I need:

1) wdt_disable block (before main)

2) Init-block. Time-out? 

3) Wdt_start or enable...

4) wdt_reset()  Should it be more code before?

 

I need to stop wdt before the sleep(Power_down) I suppose. What about restart wdt after wakeup? 

I don't need to set FUSE WDTON? I only need a reset.

 

It seems simple but...Before I went home today my application went crazy restarting in high speed. Now, I read that I need to reset and disable the WD before main(). So. That is a block to...

 

Can anyone give me some hints? There lots of macros. Should I use them or should I go direct to bit-manipulate the registers? macros are nice but using setbit/clearbit are more easy to understand I must say.

 

(regarding my last thread; The UART:s working very well now. Thanks)

This topic has a solution.
Last Edited: Thu. Sep 6, 2018 - 01:45 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the theory is just simple:

Call

wdt_enable(WDTO_500MS);

at the beginning of your program.

And in your main loop call

wdt_reset();

Just try it like this. (I presuppose that a main loop cycle never takes longer than 500ms.)

 

 

But there is a hint that on newer devices the watch dog timer stays enabled, see example code at

https://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

 

 

Personally I recommend using a watchdog timer only in a release version (not in a debug or test version).

Depending on the application a watchdog reset *may* not be noted and *may* hide critical errors.

So, if you debug or if you have a test version, you do want to know if the controller hangs, because it shows that there is still something to improve...

 

 

In the beginning was the Word, and the Word was with God, and the Word was God.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The macron you mention are those I have tested.

When my device got crazy, I realized it was not enough with wdr_reset. There is something missing.

When I read all the examples that exist, they provide different answers.

The most important thing I found was that a quick reset and shutdown of watchdog was required immediately upon launch.

According to some examples, this resetcode was written in an area that I haven't seen before. (I'm using Atmel Studio 7)

 

Some examples also say that a flag must be reset before wdt reset. Does macrot do it or must I do it manually?
Unfortunately, I'm out of time. Wish I could study the details more.

 

Used Google Translate. 

Last Edited: Thu. Sep 6, 2018 - 04:40 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Have you read the documentation?:

https://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

 

Yes. I have read much before I wrote a question here.

 

What I can understand I miss the lines: 

 

MCUSR = 0;

wdt_disable();

 

in the beginning of the program. My device was resetting in high speed. 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swedman wrote:
My device was resetting in high speed.
Unhandled ISR perhaps ? (that will give the impression of "reset" though the MCUSR will show no flags as it's really a JMP 0).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swedman wrote:
regarding my last thread; The UART:s working very well now

Jolly good - so please mark the solution in that thread.

 

See Tip #5 for instructions.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One gotcha with the WDT on most mega's is once it is enabled it will remain enabled through a reset but with default values (a very short timeout value), so yes you must init it early in the startup process or you may find your code in an endless WDT reset loop.....    Don't ask me how I know this! 

Other then that, as skotti said above, it's pretty easy to use, but not always easy to understand the correct use of WDT's.

 

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Swedman wrote:
My device was resetting in high speed.
Unhandled ISR perhaps ? (that will give the impression of "reset" though the MCUSR will show no flags as it's really a JMP 0).

 

I needed to set MCUSR=0 eary in the startup-code. The WD reset the uP but don't reset the flag. It also set prescaler to 0. So you need to reset it yourself. Else U get a reset again....and again.

I put FUSE WDTON to non-active. Then WDT worked as I wanted.

 

Later, I activate the IRQ and using a counter with a limit for maximum resets.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
understand the correct use of WDT's.

Mr G has an article on that:

 

http://www.ganssle.com/watchdogs.htm

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There are a number of things I'd like to mention, in no particular order:

 

--  OP wanted the most-straightforward example, but it "didn't work".  I'd say that because we learned of WDTON that it wasn't the simplest situation.

--  Yes, there are times that the flag must be cleared early.  But it has to be an almost pathological situation where the C [which I guess we inferred along with GCC?] preamble takes longer than the min WDT interval (15ms?).

--  Instead of just clearing the flag, trap and log the value.  [I'll often use a small array in EEPROM for the reset cause along with the reset counter as the index.  Then you can examine and analyze instead of just guessing.  In this case it sounds as if the 0 value would have given a hint.]

-- While perhaps not the dead-simplest, do a WDR early in main(), before any e.g. long pauses at startup to let e.g  LCDs power up.  CodeVision does the WDR before the WDT enable sequence which also then resets the timer mechanism.

 

That of covers my thoughts on "simplest".  But wait -- there's more...

 

-- OP finds mention of ISR as the watchdog is sometimes/often used for coarse timekeeping, especially in sleeping apps.  Indeed that isn't the simplest, and when true dual-purpose (interrupt+reset) is used it can get confusing for everyone.

-- +1 for digesting the Ganssle info, and then...

 

skotti wrote:
And in your main loop call wdt_reset();

-- The single-spot for WDR is a pretty good idea.  [In practice I might have a few more such as "restore factory defaults" in EEPROM where the operation could take many milliseconds, and similar.  But still, "controlled" and not "sprinkled about".]  But IMO/IME it is not sufficient, and may defeat using the WDR entirely.  And then there will be grumbles about using the WD and how it doesn't help and ... .   From

https://www.avrfreaks.net/commen... and others:

theusch wrote:
Quote: we strobe the wdr every 50ms. In a tricky environment, that may not be the best approach. Pseudo code for IMO/IME better approach: "I should always get to my WDR spot every 50ms. I will flag all my important events to ensure the subsystems are still running. I will do the WDR when >>all<< of the needed flags are set. This includes my system timer tick, ADC-complete interrupt, power supply check, poll from master, pass through main loop, ... . If all the subsystems are operating, THEN I do the WDR and clear the flag mask."

 

At the minimum when I start a new app I have the single WDR in the main loop at the point that I service my [usually 10ms] "tick" flag.  So I know the main loop is looping and interrupts are firing and my timekeeping is working.

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

skotti wrote:
Personally I recommend using a watchdog timer only in a release version (not in a debug or test version).

joeymorin has been known to agree with you.  I disagree.  Put the WD mechanism in on the first day with the skeleton program.  Have the logging of reset events as I mentioned above.  It can save head-scratching sessions during dev.

https://www.avrfreaks.net/forum/...

 

[edit] Another prior discussion with MANY of the points above brought up.  Recommended reading:

https://www.avrfreaks.net/forum/...

Be sure to take the links in https://www.avrfreaks.net/commen...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Thu. Sep 6, 2018 - 03:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin has been known to agree with you.

What I actually said was:

I'd suggest not using the library calls for enabling/disabling the WDT (during debugging anyway) in your initN code. Craft your own code and omit the WDR instruction. This way any looping that your initN code undergoes (which of course it should not!) will eventually result in a WDT reset. But this is not a solution, only a means to profile the problem.

In the case of that previous thread, it was a specific recommendation to the OP as means of tracking down a bug.  The OP lacked a proper debug environment.

 

Seems I had to clarify that last time, too:

https://www.avrfreaks.net/comment/979191#comment-979191

;-)

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:
Seems I had to clarify that last time, too:

As I never forget, perhaps I need a new avatar...

Image result for elephant sunglasses

Image result for elephant sunglasses

Image result for elephant sunglasses

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

There are a number of things I'd like to mention, in no particular order:

 

--  OP wanted the most-straightforward example, but it "didn't work".  I'd say that because we learned of WDTON that it wasn't the simplest situation.

--  Yes, there are times that the flag must be cleared early.  But it has to be an almost pathological situation where the C [which I guess we inferred along with GCC?] preamble takes longer than the min WDT interval (15ms?).

--  Instead of just clearing the flag, trap and log the value.  [I'll often use a small array in EEPROM for the reset cause along with the reset counter as the index.  Then you can examine and analyze instead of just guessing.  In this case it sounds as if the 0 value would have given a hint.]

-- While perhaps not the dead-simplest, do a WDR early in main(), before any e.g. long pauses at startup to let e.g  LCDs power up.  CodeVision does the WDR before the WDT enable sequence which also then resets the timer mechanism.

 

That of covers my thoughts on "simplest".  But wait -- there's more...

 

-- OP finds mention of ISR as the watchdog is sometimes/often used for coarse timekeeping, especially in sleeping apps.  Indeed that isn't the simplest, and when true dual-purpose (interrupt+reset) is used it can get confusing for everyone.

-- +1 for digesting the Ganssle info, and then...

......

 

I appreciate your opinions. Tomorrow, the product will be delivered for testing on an EMC lab. If the tests go well then the development continues.

 

This week I had four goals.

 

  1. Have transparent communication between both serial ports.
  2. Get the power down to less than 10 uA.
  3. Enable WD and BOD.
  4. Control the attached hardware using commands from both serial ports.
     

I succeeded. What I did not have time to do was to study all parts of the processor.

 

The next step is to improve the code.

Temperature-tests. Do I need an external crystal because of the UART? 

Better WD.

Lower power-consumtion.

Fail-tests.

More commands. (status etc)

(Translated by Google Translate)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swedman wrote:
I succeeded.
Well done! ... the sum total of your four goals is not easy.

Swedman wrote:
The next step is to improve the code.

...

Better WD.

A watchdog is use of hardware to flag defects that are usually software defects.

Consider use of software to process software defects (assertions, exceptions)

Consider use of software to identify software defects (lint)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. Yes. I going to rebuild my Labview program to emulate the two nodes. I can then let Labview stress this little "bridge". With Labview I can make different scenarios producing via COM-port wrong commands, fragments of commands and so on and at the same time can Labview monitor and record the behavior of the "bridge". 

 

Tomorrow it going to be a good friday. I can clean my desk. :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swedman wrote:
With Labview I can make different scenarios producing via COM-port wrong commands, fragments of commands and so on and at the same time can Labview monitor and record the behavior of the "bridge".
A fyi to the audience as I didn't know what that looks like (it's cool!)

PJRC

PJRC

Using Other Languages with Teensy USB

https://www.pjrc.com/teensy/languages.html

(mid-page)

LabVIEW

LINX replaces older libraries for using Labview.

This modified Arduino code allows Teensy 2.0 or Teensy++ 2.0 to work with LabVIEW's Arduino library.

Special thanks to Nicholas Ross for testing and providing these LabVIEW images:

 

      

 

See this conversation regarding use of Teensy 3.1 with LabVIEW.

LabVIEW is inexpensive (50USD, 65EUR) for personal and private operators (Windows only)

The LabVIEW Base subscription is relatively inexpensive for commercial operators (Windows only)

LabVIEW is multi-platform for the complete and professional versions.

 

https://www.labviewmakerhub.com/doku.php?id=get_labview

http://www.ni.com/en-us/shop/labview/select-edition.html

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

 

LabVIEW is inexpensive (50USD, 65EUR) for personal and private operators (Windows only)

The LabVIEW Base subscription is relatively inexpensive for commercial operators (Windows only)

LabVIEW is multi-platform for the complete and professional versions.

 

https://www.labviewmakerhub.com/doku.php?id=get_labview

http://www.ni.com/en-us/shop/labview/select-edition.html

 

 

It is a very powerful programming language with much software modules. It is important you spend some time to plan your code on paper before you start coding.  It can get messy if you don't plan what you really want to do. 

LV has a wide range of hardware. Most HW are expensive but there are also inexpensive. The best thing with LV are that you get a good GUI very quick.

 

You can download Labview for Students for free. I can post the link  if I find it.

 

T

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Swedman wrote:
It is important you spend some time to plan your code on paper before you start coding.
That's true of any programming language! :-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Swedman wrote:

It is important you spend some time to plan your code on paper before you start coding.

 

That's true of any programming language! :-)

 

More or less. Labview can very very easy get cluttered if you don't think twice. Modual programming are very important. I have many messy programs that start small and getting bigger and bigger. Yuck!  :-(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Swedman wrote:

clawson wrote:

 

Swedman wrote:

It is important you spend some time to plan your code on paper before you start coding.

That's true of any programming language! :-)

More or less. 

No, I don't think there's any "more or less" about it - it really is just a basic thing, which applies to any programming language!

 

In fact, it's not just programming - also applies to hardware, etc ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
As I never forget, perhaps I need a new avatar...

Image result for elephant in sunglasses

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Anyone British may recognize that as looking awfully like The Pink Pongo!