KE1 WDOG Prescaler Inaccuracies with LPO Clock

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

KE1 WDOG Prescaler Inaccuracies with LPO Clock

Jump to solution
194 Views
sean_dvorscak
Contributor III

I am trying to run WDOG with a 20ms timeout.

I've configured the WDOG_CS for LPO clock source (128kHz) and PRES = 1, and WDOG_TOVAL = 0x000A.

That should be 10/(128,000/256) = 10/500 = 0.02s.

However, I started noticing some inconsistencies that led me to believe I am overrunning the 20ms in my SW, but the WDOG wasn't resetting me. I then instrumented my code to Set/Clear a GPIO pin to see how much time was elapsing before I refreshed the WDOG, and saw 20.67ms from refresh to refresh.

I was curious to see how long the WDOG timeout is actually set for, so I then added some dummy delays just after refreshing the WDOG that would just wait for the WDOG to reset. The Oscope showed 24ms from refresh to timeout.

I then confirmed using the CLKOUT pin that the LPO clock was indeed running at 128kHz.

Frustrated, I then switched my clock source to the SIRC and adjusted the TOVAL = 625 (625/[8MHz/256] = 625/31250 = 0.02s). Running the same test as before, I saw 20ms on the dot.

I got confused so I then reverted back to the LPO clock, but removed the prescaler. I was concerned that the low frequency was causing some sort of error. When reverting back to the LPO clock without prescaler, and setting TOVAL = 2560 (2560/128000 = 0.02s), I started to see 20ms timeouts from the WDOG.

My question is why did I see such a huge accuracy hit when using the prescaler with the LPO clock? I didn't see the accuracy hit with the SIRC using prescaler. Is there a known error when it comes to this configuration? Frequency too low?

Very confused.

0 Kudos
Reply
1 Solution
133 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello @sean_dvorscak 

Your theoretical calculation is correct: with a 128 kHz LPO clock and WDOG_CS[PRES] = 1 , the WDOG clock becomes 500 Hz. Therefore, with TOVAL = 10 , the theoretical timeout is 20 ms.

However, in this configuration, the counter tick is 2 ms, and TOVAL = 10 is a very small count value. Any internal synchronization, configuration update, or refresh-path latency can therefore be magnified into millisecond-level timing differences.  Therefore, we do not recommend using LPO + ÷256 with such a small TOVAL value to implement an accurate 20 ms watchdog timeout.

If a 20 ms timeout is required, we recommend using the LPO without the prescaler and setting TOVAL = 2560 , or using the 8 MHz SIRC with ÷256 and setting TOVAL = 625 .

If the software refresh interval may reach 20.67 ms, we also recommend increasing the watchdog timeout to provide sufficient design margin.

Hope it helps.

 

Thank you.

 

BR

Alice

View solution in original post

0 Kudos
Reply
2 Replies
134 Views
Alice_Yang
NXP TechSupport
NXP TechSupport

Hello @sean_dvorscak 

Your theoretical calculation is correct: with a 128 kHz LPO clock and WDOG_CS[PRES] = 1 , the WDOG clock becomes 500 Hz. Therefore, with TOVAL = 10 , the theoretical timeout is 20 ms.

However, in this configuration, the counter tick is 2 ms, and TOVAL = 10 is a very small count value. Any internal synchronization, configuration update, or refresh-path latency can therefore be magnified into millisecond-level timing differences.  Therefore, we do not recommend using LPO + ÷256 with such a small TOVAL value to implement an accurate 20 ms watchdog timeout.

If a 20 ms timeout is required, we recommend using the LPO without the prescaler and setting TOVAL = 2560 , or using the 8 MHz SIRC with ÷256 and setting TOVAL = 625 .

If the software refresh interval may reach 20.67 ms, we also recommend increasing the watchdog timeout to provide sufficient design margin.

Hope it helps.

 

Thank you.

 

BR

Alice

0 Kudos
Reply
57 Views
sean_dvorscak
Contributor III

Thanks for the clarification. I had a feeling it had something to do with the low frequency. Interesting to know that the low TOVAL is also part of the issue.

I already fixed this to use the LPO clock without the prescaler and TOVAL of 2560 as you suggested. Also added an extra WDOG refresh during this one time extended process that was overrunning the WDOG timeout.

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2387876%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3EKE1%20WDOG%20Prescaler%20Inaccuracies%20with%20LPO%20Clock%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2387876%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EI%20am%20trying%20to%20run%20WDOG%20with%20a%2020ms%20timeout.%3C%2FP%3E%3CP%3EI've%20configured%20the%20WDOG_CS%20for%20LPO%20clock%20source%20(128kHz)%20and%20PRES%20%3D%201%2C%20and%20WDOG_TOVAL%20%3D%200x000A.%3C%2FP%3E%3CP%3EThat%20should%20be%2010%2F(128%2C000%2F256)%20%3D%2010%2F500%20%3D%200.02s.%3C%2FP%3E%3CP%3EHowever%2C%20I%20started%20noticing%20some%20inconsistencies%20that%20led%20me%20to%20believe%20I%20am%20overrunning%20the%2020ms%20in%20my%20SW%2C%20but%20the%20WDOG%20wasn't%20resetting%20me.%20I%20then%20instrumented%20my%20code%20to%20Set%2FClear%20a%20GPIO%20pin%20to%20see%20how%20much%20time%20was%20elapsing%20before%20I%20refreshed%20the%20WDOG%2C%20and%20saw%2020.67ms%20from%20refresh%20to%20refresh.%3C%2FP%3E%3CP%3EI%20was%20curious%20to%20see%20how%20long%20the%20WDOG%20timeout%20is%20actually%20set%20for%2C%20so%20I%20then%20added%20some%20dummy%20delays%20just%20after%20refreshing%20the%20WDOG%20that%20would%20just%20wait%20for%20the%20WDOG%20to%20reset.%20The%20Oscope%20showed%2024ms%20from%20refresh%20to%20timeout.%3C%2FP%3E%3CP%3EI%20then%20confirmed%20using%20the%20CLKOUT%20pin%20that%20the%20LPO%20clock%20was%20indeed%20running%20at%20128kHz.%3C%2FP%3E%3CP%3EFrustrated%2C%20I%20then%20switched%20my%20clock%20source%20to%20the%20SIRC%20and%20adjusted%20the%20TOVAL%20%3D%20625%20(625%2F%5B8MHz%2F256%5D%20%3D%20625%2F31250%20%3D%200.02s).%20Running%20the%20same%20test%20as%20before%2C%20I%20saw%2020ms%20on%20the%20dot.%3C%2FP%3E%3CP%3EI%20got%20confused%20so%20I%20then%20reverted%20back%20to%20the%20LPO%20clock%2C%20but%20removed%20the%20prescaler.%20I%20was%20concerned%20that%20the%20low%20frequency%20was%20causing%20some%20sort%20of%20error.%20When%20reverting%20back%20to%20the%20LPO%20clock%20without%20prescaler%2C%20and%20setting%20TOVAL%20%3D%202560%20(2560%2F128000%20%3D%200.02s)%2C%20I%20started%20to%20see%2020ms%20timeouts%20from%20the%20WDOG.%3C%2FP%3E%3CP%3EMy%20question%20is%20why%20did%20I%20see%20such%20a%20huge%20accuracy%20hit%20when%20using%20the%20prescaler%20with%20the%20LPO%20clock%3F%20I%20didn't%20see%20the%20accuracy%20hit%20with%20the%20SIRC%20using%20prescaler.%20Is%20there%20a%20known%20error%20when%20it%20comes%20to%20this%20configuration%3F%20Frequency%20too%20low%3F%3C%2FP%3E%3CP%3EVery%20confused.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2388157%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KE1%20WDOG%20Prescaler%20Inaccuracies%20with%20LPO%20Clock%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2388157%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3E%3CFONT%20color%3D%22%23000000%22%3EHello%26nbsp%3B%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F90401%22%20target%3D%22_blank%22%3E%40sean_dvorscak%3C%2FA%3E%26nbsp%3B%3C%2FFONT%3E%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%3CSPAN%3EYour%20theoretical%20calculation%20is%20correct%3A%20with%20a%20128%20kHz%20LPO%20clock%20and%26nbsp%3BWDOG_CS%5BPRES%5D%20%3D%201%26nbsp%3B%2C%20the%20WDOG%20clock%20becomes%20500%20Hz.%20Therefore%2C%20with%26nbsp%3BTOVAL%20%3D%2010%26nbsp%3B%2C%20the%20theoretical%20timeout%20is%2020%20ms.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%3CSPAN%3E%20However%2C%20in%20this%20configuration%2C%20the%20counter%20tick%20is%202%20ms%2C%20and%26nbsp%3B%3CSTRONG%3ETOVAL%20%3D%2010%26nbsp%3Bis%20a%20very%20small%20count%20value%3C%2FSTRONG%3E.%20Any%20internal%20synchronization%2C%20configuration%20update%2C%20or%20refresh-path%20latency%20can%20therefore%20be%20magnified%20into%20millisecond-level%20timing%20differences.%26nbsp%3B%20Therefore%2C%20we%20do%20not%20recommend%20using%20LPO%20%2B%20%C3%B7256%20with%20such%20a%20small%26nbsp%3BTOVAL%26nbsp%3Bvalue%20to%20implement%20an%20accurate%2020%20ms%20watchdog%20timeout.%20%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%3CSPAN%3EIf%20a%2020%20ms%20timeout%20is%20required%2C%20%3CSTRONG%3Ewe%20recommend%20using%20the%20LPO%20without%20the%20prescaler%20and%20setting%26nbsp%3BTOVAL%20%3D%202560%26nbsp%3B%3C%2FSTRONG%3E%2C%20or%20using%20the%208%20MHz%20SIRC%20with%20%C3%B7256%20and%20setting%26nbsp%3BTOVAL%20%3D%20625%26nbsp%3B.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%3CSPAN%3E%20If%20the%20software%20refresh%20interval%20may%20reach%2020.67%20ms%2C%20we%20also%20recommend%20increasing%20the%20watchdog%20timeout%20to%20provide%20sufficient%20design%20margin.%3C%2FSPAN%3E%3C%2FP%3E%0A%3CP%20class%3D%22%22%3EHope%20it%20helps.%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20class%3D%22%22%3EThank%20you.%3C%2FP%3E%0A%3CP%20class%3D%22%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20class%3D%22%22%3EBR%3C%2FP%3E%0A%3CP%20class%3D%22%22%3EAlice%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2389199%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KE1%20WDOG%20Prescaler%20Inaccuracies%20with%20LPO%20Clock%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2389199%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EThanks%20for%20the%20clarification.%20I%20had%20a%20feeling%20it%20had%20something%20to%20do%20with%20the%20low%20frequency.%20Interesting%20to%20know%20that%20the%20low%20TOVAL%20is%20also%20part%20of%20the%20issue.%3C%2FP%3E%3CP%3EI%20already%20fixed%20this%20to%20use%20the%20LPO%20clock%20without%20the%20prescaler%20and%20TOVAL%20of%202560%20as%20you%20suggested.%20Also%20added%20an%20extra%20WDOG%20refresh%20during%20this%20one%20time%20extended%20process%20that%20was%20overrunning%20the%20WDOG%20timeout.%3C%2FP%3E%3C%2FLINGO-BODY%3E