KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep)

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

KW47: Relationship between WDOG Wait/Stop modes and Power Modes (Sleep/Deep Sleep)

652 Views
hyama
Contributor II

Hello,

I am reading the KW47 Reference Manual and I am confused about the relationship between the WDOG low-power modes and the system power modes.

In the WDOG chapter, the Control and Status register contains the following bits:

- WAIT:
"Enables WDOG to operate when the chip is in Wait mode."

- STOP:
"Enables WDOG to operate when the chip is in Stop mode."

The WDOG chapter also states that:

- The selected WDOG clock source must remain active in Stop mode.
- For Debug and Stop modes, a clock source other than the bus clock must be used.

On the other hand, the Power Modes chapter describes:

Sleep mode:
- CPU execution halted
- Core clock gated off
- System clock and bus clock may continue running

Deep Sleep mode:
- Core clock gated off
- System clock gated off
- Bus clock gated off

Based on these descriptions, it seems reasonable to interpret:

- Wait mode ≈ Sleep mode
- Stop mode ≈ Deep Sleep mode

However, I have not been able to find any explicit statement in the Reference Manual confirming this mapping.

My questions are:

1. Does WDOG Wait mode correspond to the Power Mode Sleep mode on KW47?
2. Does WDOG Stop mode correspond to the Power Mode Deep Sleep mode on KW47?
3. Or are Wait/Stop WDOG-specific CPU states that are different from the SoC power modes?
4. Is there any Reference Manual section or Application Note that explicitly describes this relationship?

Thank you for your help.

0 Kudos
Reply
5 Replies

566 Views
sofiaurueta
NXP Employee
NXP Employee

Hello, hope you are doing well.

 

The terminology used in the KW47 Reference Manual is consistent with interpreting the WAIT and STOP fields in the WDOG control register as references to chip/core low-power states, rather than as WDOG-specific CPU states. I would describe the relationship as functional correspondence rather than a strict equivalence.

In that sense, WDOG WAIT corresponds to the Wait/Sleep class condition, where CPU execution is halted but the system and bus clocks may remain available. WDOG STOP corresponds to the Stop/Deep-Sleep class condition, where the core, system, and bus clocks are gated and the watchdog can continue only if it is configured to use a clock source that remains active in that mode.

 

Best regards,
Sofia.

420 Views
hyama
Contributor II
@sofiaurueta 

I performed some additional testing and updated the post with my findings above.
Could you please let me know if my interpretation is correct?

Thank you.

0 Kudos
Reply

273 Views
sofiaurueta
NXP Employee
NXP Employee

Hi @hyama , I apologize for the late reply.

 

Are you testing with any example from the SDK? How are you confirming that the device is entering Deep Sleep mode?

From the behavior you described, it is possible that the device is only entering Sleep mode. If the device were entering Deep Sleep, the results would be the opposite: STOP=1 (Case 3) should have caused the timeout, and WAIT=1 (Case 2) should have had no effect. The fact that it is WAIT=1 that triggers the reset is consistent with the device entering Sleep mode, not Deep Sleep.

 

Answering your questions:

1. When the device enters a low-power mode through PWR_EnterLowPower(), is WDOG operation controlled by the WAIT bit or the STOP bit?

CS[WAIT] and CS[STOP] are independent controls for independent modes where CS[WAIT] controls WDOG operation in Sleep mode, and CS[STOP] controls WDOG operation in Deep Sleep mode.
In the case that the device enters Sleep mode, CS[WAIT] is the active control. CS[STOP] has no effect here because Deep Sleep is not entered. If the device were instead configured to enter Deep Sleep, CS[STOP] would be the active control.

 

2. Does the observed result indicate that the device is actually entering Sleep mode rather than Deep Sleep mode, or should it be interpreted as entering Deep Sleep mode?

The results are consistent with Sleep mode entry and are inconsistent with Deep Sleep. Based on the three test cases, Sleep mode is being entered.

 

3. Does the STOP bit correspond to the Deep Sleep mode described in the Power Modes chapter, or does it refer to a different low-power state?

Based on the documentation, CS[STOP] corresponds to Deep Sleep, and the behavior observed in the tests is consistent with this (assuming that Deep Sleep was not entered).

 

4. How should the following entries in Table 225 be interpreted with respect to the WDOG WAIT and STOP control bits?

The "Optional" for Deep Sleep means the WDOG can operate in Deep Sleep if CS[STOP]=1 and a clock source other than the bus clock is configured. For Debug and Stop modes, a clock source other than the bus clock must be used. Using the bus clock the watchdog can be "enabled" architecturally but its clock is gone, unless a different clock source is selected, for example, 32K_CLK.

 

Best regards,
Sofia.

43 Views
hyama
Contributor II

Hi @sofiaurueta 
Thank you for your previous explanation.

>Are you testing with any example from the SDK? How are you confirming that the device is entering Deep Sleep mode?

Regarding your question, the test was not performed on an SDK example project. It was performed on our application based on the NXP SDK.
To verify whether the device enters Deep Sleep mode, I performed some additional investigation and found that the following path is executed when entering low-power mode:

vPortSuppressTicksAndSleep()
-> PWR_EnterLowPower()
-> PM_EnterLowPower()
-> PM_EnterLowPowerMode()
-> CMC_EnterLowPowerMode()


In CMC_EnterLowPowerMode(), the SDK sets the SLEEPDEEP bit in the SCB->SCR register before executing WFI.
Our understanding is that setting the SLEEPDEEP bit and executing WFI means that the device enters Deep Sleep mode. Could you please confirm whether this understanding is correct for KW47?
I am asking because my WDOG test results appear to depend on the WAIT bit rather than the STOP bit.


Thank you for your help.

 

0 Kudos
Reply

557 Views
hyama
Contributor II

Hello Sofia,

Thank you for your previous explanation.

Based on your reply, my understanding is:

- WDOG WAIT corresponds to a Wait/Sleep-class low-power condition.
- WDOG STOP corresponds to a Stop/Deep-Sleep-class low-power condition.
- The relationship is a functional correspondence rather than a strict one-to-one mapping.

After reviewing the KW47 Reference Manual again, I found the following section:

28.4 Module operation in low power modes
Table 225: Cortex M33 core module operation in low power modes

For WDOGx, the table shows:

- Sleep : ON
- Deep Sleep : Optional
- Power Down : Optional
- Deep Power Down : OFF

From this table, I interpreted that WDOG operation can be configured in at least Deep Sleep and Power Down modes.

To better understand the behavior, I performed a test using a KW47-Loc evaluation board.

Test conditions:

- WDOG enabled
- WDOG refresh is performed from vApplicationIdleHook()
- PWR_EnterLowPower() is executed from FreeRTOS vPortSuppressTicksAndSleep()
- Observe whether a watchdog reset occurs after entering the low-power state

Test results:

Case 1
WAIT=0, STOP=0
→ No watchdog reset occurred

Case 2
WAIT=1, STOP=0
→ Watchdog reset occurred

Case 3
WAIT=0, STOP=1
→ No watchdog reset occurred

My interpretation is that when a watchdog reset occurred, the device entered a low-power state where vApplicationIdleHook() was no longer executed while the watchdog continued running and eventually timed out.

However, a watchdog reset occurred only when WAIT=1 and STOP=0, while no watchdog reset occurred when STOP=1.

Because of this result, I am having difficulty understanding how the WAIT and STOP bits are actually applied to watchdog operation during low-power modes.

Could you please clarify the following points?

1. When the device enters a low-power mode through PWR_EnterLowPower(), is WDOG operation controlled by the WAIT bit or the STOP bit?

2. Does the observed result indicate that the device is actually entering Sleep mode rather than Deep Sleep mode, or should it be interpreted as entering Deep Sleep mode?

3. Does the STOP bit correspond to the Deep Sleep mode described in the Power Modes chapter, or does it refer to a different low-power state?

4. How should the following entries in Table 225 be interpreted with respect to the WDOG WAIT and STOP control bits?
- WDOGx : Optional (Deep Sleep)
- WDOGx : Optional (Power Down)

Thank you for your support.

0 Kudos
Reply
%3CLINGO-SUB%20id%3D%22lingo-sub-2407900%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3EKW47%3A%20Relationship%20between%20WDOG%20Wait%2FStop%20modes%20and%20Power%20Modes%20(Sleep%2FDeep%20Sleep)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2407900%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%2C%3C%2FP%3E%3CP%3EI%20am%20reading%20the%20KW47%20Reference%20Manual%20and%20I%20am%20confused%20about%20the%20relationship%20between%20the%20WDOG%20low-power%20modes%20and%20the%20system%20power%20modes.%3C%2FP%3E%3CP%3EIn%20the%20WDOG%20chapter%2C%20the%20Control%20and%20Status%20register%20contains%20the%20following%20bits%3A%3C%2FP%3E%3CP%3E-%20WAIT%3A%3CBR%20%2F%3E%22Enables%20WDOG%20to%20operate%20when%20the%20chip%20is%20in%20Wait%20mode.%22%3C%2FP%3E%3CP%3E-%20STOP%3A%3CBR%20%2F%3E%22Enables%20WDOG%20to%20operate%20when%20the%20chip%20is%20in%20Stop%20mode.%22%3C%2FP%3E%3CP%3EThe%20WDOG%20chapter%20also%20states%20that%3A%3C%2FP%3E%3CP%3E-%20The%20selected%20WDOG%20clock%20source%20must%20remain%20active%20in%20Stop%20mode.%3CBR%20%2F%3E-%20For%20Debug%20and%20Stop%20modes%2C%20a%20clock%20source%20other%20than%20the%20bus%20clock%20must%20be%20used.%3C%2FP%3E%3CP%3EOn%20the%20other%20hand%2C%20the%20Power%20Modes%20chapter%20describes%3A%3C%2FP%3E%3CP%3ESleep%20mode%3A%3CBR%20%2F%3E-%20CPU%20execution%20halted%3CBR%20%2F%3E-%20Core%20clock%20gated%20off%3CBR%20%2F%3E-%20System%20clock%20and%20bus%20clock%20may%20continue%20running%3C%2FP%3E%3CP%3EDeep%20Sleep%20mode%3A%3CBR%20%2F%3E-%20Core%20clock%20gated%20off%3CBR%20%2F%3E-%20System%20clock%20gated%20off%3CBR%20%2F%3E-%20Bus%20clock%20gated%20off%3C%2FP%3E%3CP%3EBased%20on%20these%20descriptions%2C%20it%20seems%20reasonable%20to%20interpret%3A%3C%2FP%3E%3CP%3E-%20Wait%20mode%20%E2%89%88%20Sleep%20mode%3CBR%20%2F%3E-%20Stop%20mode%20%E2%89%88%20Deep%20Sleep%20mode%3C%2FP%3E%3CP%3EHowever%2C%20I%20have%20not%20been%20able%20to%20find%20any%20explicit%20statement%20in%20the%20Reference%20Manual%20confirming%20this%20mapping.%3C%2FP%3E%3CP%3EMy%20questions%20are%3A%3C%2FP%3E%3CP%3E1.%20Does%20WDOG%20Wait%20mode%20correspond%20to%20the%20Power%20Mode%20Sleep%20mode%20on%20KW47%3F%3CBR%20%2F%3E2.%20Does%20WDOG%20Stop%20mode%20correspond%20to%20the%20Power%20Mode%20Deep%20Sleep%20mode%20on%20KW47%3F%3CBR%20%2F%3E3.%20Or%20are%20Wait%2FStop%20WDOG-specific%20CPU%20states%20that%20are%20different%20from%20the%20SoC%20power%20modes%3F%3CBR%20%2F%3E4.%20Is%20there%20any%20Reference%20Manual%20section%20or%20Application%20Note%20that%20explicitly%20describes%20this%20relationship%3F%3C%2FP%3E%3CP%3EThank%20you%20for%20your%20help.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2409007%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KW47%3A%20Relationship%20between%20WDOG%20Wait%2FStop%20modes%20and%20Power%20Modes%20(Sleep%2FDeep%20Sleep)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2409007%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%20lang%3D%22es-419%22%3EHello%2C%20hope%20you%20are%20doing%20well.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3EThe%20terminology%20used%20in%20the%20KW47%20Reference%20Manual%20is%20consistent%20with%20interpreting%20the%20WAIT%20and%20STOP%20fields%20in%20the%20WDOG%20control%20register%20as%20references%20to%20chip%2Fcore%20low-power%20states%2C%20rather%20than%20as%20WDOG-specific%20CPU%20states.%20I%20would%20describe%20the%20relationship%20as%20functional%20correspondence%20rather%20than%20a%20strict%20equivalence.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3EIn%20that%20sense%2C%20WDOG%20WAIT%20corresponds%20to%20the%20Wait%2FSleep%20class%20condition%2C%20where%20CPU%20execution%20is%20halted%20but%20the%20system%20and%20bus%20clocks%20may%20remain%20available.%20WDOG%20STOP%20corresponds%20to%20the%20Stop%2FDeep-Sleep%20class%20condition%2C%20where%20the%20core%2C%20system%2C%20and%20bus%20clocks%20are%20gated%20and%20the%20watchdog%20can%20continue%20only%20if%20it%20is%20configured%20to%20use%20a%20clock%20source%20that%20remains%20active%20in%20that%20mode.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3EBest%20regards%2C%3CBR%20%2F%3ESofia.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2409101%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KW47%3A%20Relationship%20between%20WDOG%20Wait%2FStop%20modes%20and%20Power%20Modes%20(Sleep%2FDeep%20Sleep)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2409101%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%3EHello%20Sofia%2C%3C%2FP%3E%3CP%3EThank%20you%20for%20your%20previous%20explanation.%3C%2FP%3E%3CP%3EBased%20on%20your%20reply%2C%20my%20understanding%20is%3A%3C%2FP%3E%3CP%3E-%20WDOG%20WAIT%20corresponds%20to%20a%20Wait%2FSleep-class%20low-power%20condition.%3CBR%20%2F%3E-%20WDOG%20STOP%20corresponds%20to%20a%20Stop%2FDeep-Sleep-class%20low-power%20condition.%3CBR%20%2F%3E-%20The%20relationship%20is%20a%20functional%20correspondence%20rather%20than%20a%20strict%20one-to-one%20mapping.%3C%2FP%3E%3CP%3EAfter%20reviewing%20the%20KW47%20Reference%20Manual%20again%2C%20I%20found%20the%20following%20section%3A%3C%2FP%3E%3CP%3E28.4%20Module%20operation%20in%20low%20power%20modes%3CBR%20%2F%3ETable%20225%3A%20Cortex%20M33%20core%20module%20operation%20in%20low%20power%20modes%3C%2FP%3E%3CP%3EFor%20WDOGx%2C%20the%20table%20shows%3A%3C%2FP%3E%3CP%3E-%20Sleep%20%3A%20ON%3CBR%20%2F%3E-%20Deep%20Sleep%20%3A%20Optional%3CBR%20%2F%3E-%20Power%20Down%20%3A%20Optional%3CBR%20%2F%3E-%20Deep%20Power%20Down%20%3A%20OFF%3C%2FP%3E%3CP%3EFrom%20this%20table%2C%20I%20interpreted%20that%20WDOG%20operation%20can%20be%20configured%20in%20at%20least%20Deep%20Sleep%20and%20Power%20Down%20modes.%3C%2FP%3E%3CP%3ETo%20better%20understand%20the%20behavior%2C%20I%20performed%20a%20test%20using%20a%20KW47-Loc%20evaluation%20board.%3C%2FP%3E%3CP%3ETest%20conditions%3A%3C%2FP%3E%3CP%3E-%20WDOG%20enabled%3CBR%20%2F%3E-%20WDOG%20refresh%20is%20performed%20from%20vApplicationIdleHook()%3CBR%20%2F%3E-%20PWR_EnterLowPower()%20is%20executed%20from%20FreeRTOS%20vPortSuppressTicksAndSleep()%3CBR%20%2F%3E-%20Observe%20whether%20a%20watchdog%20reset%20occurs%20after%20entering%20the%20low-power%20state%3C%2FP%3E%3CP%3ETest%20results%3A%3C%2FP%3E%3CP%3ECase%201%3CBR%20%2F%3EWAIT%3D0%2C%20STOP%3D0%3CBR%20%2F%3E%E2%86%92%20No%20watchdog%20reset%20occurred%3C%2FP%3E%3CP%3ECase%202%3CBR%20%2F%3EWAIT%3D1%2C%20STOP%3D0%3CBR%20%2F%3E%E2%86%92%20Watchdog%20reset%20occurred%3C%2FP%3E%3CP%3ECase%203%3CBR%20%2F%3EWAIT%3D0%2C%20STOP%3D1%3CBR%20%2F%3E%E2%86%92%20No%20watchdog%20reset%20occurred%3C%2FP%3E%3CP%3EMy%20interpretation%20is%20that%20when%20a%20watchdog%20reset%20occurred%2C%20the%20device%20entered%20a%20low-power%20state%20where%20vApplicationIdleHook()%20was%20no%20longer%20executed%20while%20the%20watchdog%20continued%20running%20and%20eventually%20timed%20out.%3C%2FP%3E%3CP%3EHowever%2C%20a%20watchdog%20reset%20occurred%20only%20when%20WAIT%3D1%20and%20STOP%3D0%2C%20while%20no%20watchdog%20reset%20occurred%20when%20STOP%3D1.%3C%2FP%3E%3CP%3EBecause%20of%20this%20result%2C%20I%20am%20having%20difficulty%20understanding%20how%20the%20WAIT%20and%20STOP%20bits%20are%20actually%20applied%20to%20watchdog%20operation%20during%20low-power%20modes.%3C%2FP%3E%3CP%3ECould%20you%20please%20clarify%20the%20following%20points%3F%3C%2FP%3E%3CP%3E1.%20When%20the%20device%20enters%20a%20low-power%20mode%20through%20PWR_EnterLowPower()%2C%20is%20WDOG%20operation%20controlled%20by%20the%20WAIT%20bit%20or%20the%20STOP%20bit%3F%3C%2FP%3E%3CP%3E2.%20Does%20the%20observed%20result%20indicate%20that%20the%20device%20is%20actually%20entering%20Sleep%20mode%20rather%20than%20Deep%20Sleep%20mode%2C%20or%20should%20it%20be%20interpreted%20as%20entering%20Deep%20Sleep%20mode%3F%3C%2FP%3E%3CP%3E3.%20Does%20the%20STOP%20bit%20correspond%20to%20the%20Deep%20Sleep%20mode%20described%20in%20the%20Power%20Modes%20chapter%2C%20or%20does%20it%20refer%20to%20a%20different%20low-power%20state%3F%3C%2FP%3E%3CP%3E4.%20How%20should%20the%20following%20entries%20in%20Table%20225%20be%20interpreted%20with%20respect%20to%20the%20WDOG%20WAIT%20and%20STOP%20control%20bits%3F%3CBR%20%2F%3E-%20WDOGx%20%3A%20Optional%20(Deep%20Sleep)%3CBR%20%2F%3E-%20WDOGx%20%3A%20Optional%20(Power%20Down)%3C%2FP%3E%3CP%3EThank%20you%20for%20your%20support.%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2410385%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KW47%3A%20Relationship%20between%20WDOG%20Wait%2FStop%20modes%20and%20Power%20Modes%20(Sleep%2FDeep%20Sleep)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2410385%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CDIV%3E%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F242964%22%20target%3D%22_blank%22%3E%40sofiaurueta%3C%2FA%3E%26nbsp%3B%3CBR%20%2F%3E%3CP%3EI%20performed%20some%20additional%20testing%20and%20updated%20the%20post%20with%20my%20findings%20above.%3CBR%20%2F%3ECould%20you%20please%20let%20me%20know%20if%20my%20interpretation%20is%20correct%3F%3C%2FP%3E%3CP%3EThank%20you.%3C%2FP%3E%3C%2FDIV%3E%3C%2FLINGO-BODY%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2411792%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%20translate%3D%22no%22%3ERe%3A%20KW47%3A%20Relationship%20between%20WDOG%20Wait%2FStop%20modes%20and%20Power%20Modes%20(Sleep%2FDeep%20Sleep)%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2411792%22%20slang%3D%22en-US%22%20mode%3D%22CREATE%22%3E%3CP%20lang%3D%22es-419%22%3EHi%20%3CA%20href%3D%22https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F265890%22%20target%3D%22_blank%22%3E%40hyama%3C%2FA%3E%26nbsp%3B%2C%20I%20apologize%20for%20the%20late%20reply.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%3EAre%20you%20testing%20with%20any%20example%20from%20the%20SDK%3F%20How%20are%20you%20confirming%20that%20the%20device%20is%20entering%20Deep%20Sleep%20mode%3F%3C%2FP%3E%0A%3CP%3EFrom%20the%20behavior%20you%20described%2C%20it%20is%20possible%20that%20the%20device%20is%20only%20entering%20Sleep%20mode.%20If%20the%20device%20were%20entering%20Deep%20Sleep%2C%20the%20results%20would%20be%20the%20opposite%3A%20STOP%3D1%20(Case%203)%20should%20have%20caused%20the%20timeout%2C%20and%20WAIT%3D1%20(Case%202)%20should%20have%20had%20no%20effect.%20The%20fact%20that%20it%20is%20WAIT%3D1%20that%20triggers%20the%20reset%20is%20consistent%20with%20the%20device%20entering%20Sleep%20mode%2C%20not%20Deep%20Sleep.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3EAnswering%20your%20questions%3A%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E1.%20When%20the%20device%20enters%20a%20low-power%20mode%20through%20PWR_EnterLowPower()%2C%20is%20WDOG%20operation%20controlled%20by%20the%20WAIT%20bit%20or%20the%20STOP%20bit%3F%3C%2FP%3E%0A%3CP%3ECS%5BWAIT%5D%20and%20CS%5BSTOP%5D%20are%20independent%20controls%20for%20independent%20modes%20where%20CS%5BWAIT%5D%20controls%20WDOG%20operation%20in%20Sleep%20mode%2C%20and%20CS%5BSTOP%5D%20controls%20WDOG%20operation%20in%20Deep%20Sleep%20mode.%20%3CBR%20%2F%3EIn%20the%20case%20that%20the%20device%20enters%20Sleep%20mode%2C%20CS%5BWAIT%5D%20is%20the%20active%20control.%20CS%5BSTOP%5D%20has%20no%20effect%20here%20because%20Deep%20Sleep%20is%20not%20entered.%20If%20the%20device%20were%20instead%20configured%20to%20enter%20Deep%20Sleep%2C%20CS%5BSTOP%5D%20would%20be%20the%20active%20control.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E2.%20Does%20the%20observed%20result%20indicate%20that%20the%20device%20is%20actually%20entering%20Sleep%20mode%20rather%20than%20Deep%20Sleep%20mode%2C%20or%20should%20it%20be%20interpreted%20as%20entering%20Deep%20Sleep%20mode%3F%3C%2FP%3E%0A%3CP%3EThe%20results%20are%20consistent%20with%20Sleep%20mode%20entry%20and%20are%20inconsistent%20with%20Deep%20Sleep.%20Based%20on%20the%20three%20test%20cases%2C%20Sleep%20mode%20is%20being%20entered.%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E3.%20Does%20the%20STOP%20bit%20correspond%20to%20the%20Deep%20Sleep%20mode%20described%20in%20the%20Power%20Modes%20chapter%2C%20or%20does%20it%20refer%20to%20a%20different%20low-power%20state%3F%3C%2FP%3E%0A%3CP%20class%3D%22wnfdntu%20_1ibi0s3f5%20_1ibi0s3ce%20_1ibi0s3ea%22%20data-pm-slice%3D%221%201%20%5B%5D%22%3EBased%20on%20the%20documentation%2C%20CS%5BSTOP%5D%20corresponds%20to%20Deep%20Sleep%2C%20and%20the%20behavior%20observed%20in%20the%20tests%20is%20consistent%20with%20this%20(assuming%20that%20Deep%20Sleep%20was%20not%20entered).%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E%26nbsp%3B%3C%2FP%3E%0A%3CP%20lang%3D%22es-419%22%3E4.%20How%20should%20the%20following%20entries%20in%20Table%20225%20be%20interpreted%20with%20respect%20to%20the%20WDOG%20WAIT%20and%20STOP%20control%20bits%3F%3C%2FP%3E%0A%3CP%3EThe%20%22Optional%22%20for%20Deep%20Sleep%20means%20the%20WDOG%20can%20operate%20in%20Deep%20Sleep%20if%20CS%5BSTOP%5D%3D1%20and%20a%20clock%20source%20other%20than%20the%20bus%20clock%20is%20configured.%20For%20Debug%20and%20Stop%20modes%2C%20a%20clock%20source%20other%20than%20the%20bus%20clock%20must%20be%20used.%20Using%20the%20bus%20clock%20the%20watchdog%20can%20be%20%22enabled%22%20architecturally%20but%20its%20clock%20is%20gone%2C%20unless%20a%20different%20clock%20source%20is%20selected%2C%20for%20example%2C%2032K_CLK.%3C%2FP%3E%0A%3CBR%20%2F%3E%0A%3CP%3EBest%20regards%2C%3CBR%20%2F%3ESofia.%3C%2FP%3E%3C%2FLINGO-BODY%3E