About Watch Dog Timer in STOP and DOZE mode

cancel
Showing results for 
Search instead for 
Did you mean: 

About Watch Dog Timer in STOP and DOZE mode

Jump to solution
1,474 Views
Contributor IV

Hello NXP team,

I'm modifying my original comment I posted in other day.

I need NXP's support asap to solve our problem. Please advise me how to stop WDT when Vybrid is in STOP mode.

According to "VYBRIDRM: Vybrid Reference Manual: F Series - Reference Manual (REV 8)", page 1248 , I think I can stop WDT operation when Vybrid is in STOP mode. But in fact, I can't stop WDT in STOP mode and WDT keeps working even I set WDOG_WCR to "0x3F33" before I put Vybrid to STOP mode.  Could you advise me if any additional settings are needed to stop WDT in STOP mode?  Or this behavior is not supported in Vybrid?

===============

 9.7.5.4.1 STOP and DOZE mode

  If the WDOG timer disable bit for low power STOP and DOZE mode (WDZST) bit in

  the Watchdog Control Register (WDOG_WCR), is cleared, the WDOG timer continues

  to operate using the low frequency reference clock. If the low power enable (WDZST) bit

  is set, the WDOG timer operation will be suspended in low power STOP or DOZE mode.

  Upon exiting low power STOP or DOZE mode, the WDOG operation returns to what it

  was prior to entering the STOP or DOZE mode.

===============

Thanks,

Norihiro Michigami
AVNET

1 Solution
373 Views
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
36 Replies
374 Views
Community Manager
This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

View solution in original post

0 Kudos
313 Views
Contributor IV

Hello Richard,

Thank you for your update and sorry for asking you question which was already answered.

We correctly understand that we only have a chance to control WDT control register after power-up.

My colleague says that he needs to talk with our customer again to triple-check that nobody writes WDT register before they sets WDZST  to "1" and check OCOTP register as well.

Anyway, I think that we don't need to discuss further on this topic and we can close this ticket.

Thanks,

Norhiro Michigami

AVNET

0 Kudos
313 Views
NXP Employee
NXP Employee

Hi Norohiro,

No problem. We are here to help.

Best regards,

Richard

0 Kudos
313 Views
Contributor IV

Hello Richard,

Sorry, when I talked with our engineer who works with our customer again, he told me that he misunderstood your answer.

In his and his customer's case, they didn't blow the fuse for WDOG_ENABLE.

So, we believe any initial boot loader in bootrom doesn't write a value to WDOG_WCR register during the boot. 

But still writing '1' to WDOG_WCR[WDZST] from customer's program is not effective.  Customer is sure that it is first write operation to WDZST bit from their application.

To make sure, any code in the bootrom never writes to WDOG_WCR register when the fuse for WDOG_ENABLE is _not_ blown? 

And we have one question about WDOG_WCR.  Your RM said,

  "WDZST, WDBG and WDW are write-once only bits. Once the software does a write access to these bits, they will be locked and cannot be reprogrammed until the next system reset assertion."

We know that the default value of WDZST is "0".

If someone writes '0' to WDZST ( i.e., default value "0" is not changed by this write.) before customer's application writes '1' to WDZST bit, WDZST bit will be locked by "0"  even though the actual value of WDZST bit is not changed? 

In our understanding, "write once bit" is locked if we write a value which modifies the default value of "write once bit". But we want to make sure this point for WDZST bit.

Thanks,

Norihiro Michigami

AVNET

0 Kudos
313 Views
NXP Employee
NXP Employee

Hi Norihiro,

I already said previously that writing a 0 will also count as a write:

"You have to make absolutely sure that the WDOG_WCR register is written only once. Any further writes will be ignored. For example, if the watchdog was initialized during startup without the disable flags set, then the flags cannot be set anymore. "

Thus, the write-once bits can be written only once means that the very first write to the WDOG_WCR register locks the write-once bits. It does not matter if the bit value was 0 or 1, the bit will be locked after the first write..

So, please make sure the bits are set to the desired state at the very first write to WDOG_WCR.

Also, please ask your customer to read the OCOTP register and check if the fuse is blown or not. Check if the WDOG_WCR was not written before when SW sets the WDW and WDZS bits.

Ex. If WDOG_WCR[WDE] is set (watchdog is enabled), then WDOG_WCR was written before and the write-once bits will be locked.

Regards,

Richard

313 Views
Contributor IV

Hello Richard,

Thank you for your update. We found that WDOG_ENABLE was blown in our customer's case.

So, our write operation to WDOG_WCR register was 2nd write after the power-up.

Thank you for all of NXP guy's help on this topic.  Now I'm closing  this case.

Thanks,

Norihiro Michigami

AVNET

0 Kudos
313 Views
Contributor IV

Hello Richard,

Thank you for your test. I understand the WDT reset can be masked on your setup.

Could you help me two more items?

1.  Initial boot loader code (which is stored in Vybrid internal ROM) for NAND boot doesn't write anything to WDOG_WCR during its start-up process?  I didn't tell you, but our customer uses NAND boot. Because we don't have the initial boot loader source code, we don't know if it writes WDOG_WCR before we can get control of WDOG_WCR. 

2.  Could you give us DIFF file between the original low-power demo from MQX4.2 and the source code you modified for your test? We want to try the same test on our tower board.Thanks,

Norihiro Michigami

AVNET

0 Kudos
313 Views
NXP Employee
NXP Employee

Hi Norihiro,

The boot rom will use the watchdog if fuse WDOG_ENABLE is blown. You can check this is the OCOTP_CFG5 register (bit 21). This fuse is not blown on standard parts.

You can also check if you can write the WDOG_WCR register. Just read back the register and check if the bits you wanted to set are effectively set. If they are  not set than there was a previous write to that register.

I do not have a diff for my changes, but it is real easy. Below are screen dumps. The file to change is power_mode.c

To disable WD for wait mode:wait_mode.png

To disable for stop mode:

stop_mode.png

Regards,

Richard

313 Views
NXP Employee
NXP Employee

Hello Norihiro-san,

R&D test with validation software, which is basically bare metal software with hooks to test equipment.

In essence, they used the interrupt feature to test the functionality. i.e. they tested if an interrupt was triggered after the time-out. When in wait mode, with the wait disable set, there was no wakeup and no interrupt.

Now, I did my own quick test. I used the low-power demo from MQX4.2. This demo cycles to all different power modes.

When I set the WDW bit, just before the chip is placed into wait mode, then there is no reset. I have the timeout set to 15 seconds and wait for more than one minute. When I press the wakeup button (part of the demo code), the code continues as normal, but since the code does not service the watchdog, the watchdog resets the part after 15 seconds. This proves that the watchdog was initialized.

The same works also for stop mode and the WDZST bit set in the WDOG_WCR register.

You have to make absolutely sure that the WDOG_WCR register is written only once. Any further writes will be ignored. For example, if the watchdog was initialized during startup without the disable flags set, then the flags cannot be set anymore. So, check if the flags are on after setting them. Also make sure the device is actually in the wait or stop mode and did not incidentally exit wait/stop mode.

Best regards,

Richard

0 Kudos
313 Views
Contributor IV

Hello Karina-san, Jiri-san, Richard-san,

Thank you for your help. We already confirmed the reset source based on status bit after clearing it on POR time.

We could see WDOG reset bit.

Do you see the same result in the "STOP" mode also?  

And I'm not sure how you tested this feature on your side, but could you give us more detailed procedure that you applied?

I want to apply the same procedure to my test setup.

Thanks,

Norihiro Michigami

0 Kudos
313 Views
NXP Apps Support
NXP Apps Support

norihiromichigami

did you get previous comment from Richard?

0 Kudos
313 Views
NXP Apps Support
NXP Apps Support

jiri-b36968​ can you comment please?

0 Kudos
313 Views
NXP Apps Support
NXP Apps Support

jiri-b36968​ FYI

0 Kudos
313 Views
Contributor IV

Hello Jiri-san,

Sorry for delaying in my response.

Are you asking me if I changed WDW bit only once?

If so, yes, we know WDW bit is write once bit, so I changed it only once after Vybrid was brought up.

Thanks,

Norihiro Michigami

0 Kudos
313 Views
NXP Employee
NXP Employee

Hello Norihiro-san,

I am covering for Jiri as he is currently on business travel.

I checked with design about this issue. They tested and confirmed the watchdog suspend in wait mode (WDW) is working.

Can you veriify on your system if it is actually the watchdog that did reset the system?

The SRC_SRSR register contains status flags indicating which reset source caused the reset. You should clear this register after power-on (POR) and check the status flags after the watchdog reset.

Regards,

Richard

313 Views
NXP Apps Support
NXP Apps Support

norihiromichigami​ did you get previous comment?

0 Kudos
313 Views
NXP Apps Support
NXP Apps Support

jiri-b36968​ do you have an update of this  case?

0 Kudos
313 Views
NXP Employee
NXP Employee

Hello,

went through the thread.

Presume that you changed the setting only once. WDW is write once only bit - please confirm.

Checking with designers. Sorry for delay.

/Jiri

313 Views
NXP Apps Support
NXP Apps Support

CT Assigned.

0 Kudos
313 Views
NXP Employee
NXP Employee

Hi karinavalencia,​ Created CT: 48111380

0 Kudos