UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

The Zynq SoC’s Private Watchdog: Adam Taylor’s MicroZed Chronicles Part 16

by Xilinx Employee ‎01-21-2014 02:34 PM - edited ‎04-17-2014 01:26 PM (71,858 Views)

In the last blog we looked at the private timers provided with each CPU in the Zynq All Programmable SoC. In this blog we will look at the Zynq SoC’s private watchdog timer, how you can use it, and we’ll look at an example of its use.

 

However, before we look at how we can configure and use the Zynq watchdog, I think it would be a good idea to explore why you might need a watchdog timer and how a watchdog works. Watchdogs address the inevitability of unresponsive software and provide a reliable solution to this problem. No matter what the end application, all engineers want to provide a reliable solution and good system designers know they must design for all eventualities.

 

A system-engineering team must undertake a number of steps to ensure a reliable design. The first step is to establish a requirements baseline that defines the behavior of the system and its software. The engineering team then implements these requirements, following a software life cycle that includes:

 

  • Generation of the design documentation
  • Software design and source coding
  • A validation strategy to verify that the requirements have been achieved

 

Most designs will include methods to ensure that the software can respond rationally to system faults. These faults can have one of two effects—either allowing the software to continue operation while maintaining either a full or reduced service or complete failure to respond. When the software fails to respond, a watchdog timer can either restart the system or ensure that the system fails safely. (The issue of safety critical systems and software is a complex one and would take more room than I have here to cover in detail here.)

 

In the very simplest sense a watchdog is a timer that counts down from a pre-loaded value. As the software application executes, it periodically resets the watchdog. Should the software fail to reset the watchdog, its count will reach zero and the watchdog circuit then resets the processor. When the software is operating normally, the watchdog count never reaches zero. If the software fails for some reason, then the watchdog is not reset, the count reaches zero, the processor is reset, and the software reboots. Many systems have a register with a bit that’s set when the watchdog triggers. This feature allows the system to come up back from the watchdog reset while noting the fact that the watchdog triggered the reset.

 

Each of the two ARM Cortex-A9 processors within the Zynq SoC has a private watchdog timer. These private watchdogs can be used as either a timer like the private timer (discussed in the previous blog post in this series) or as a watchdog. The Zynq watchdog timer is controlled via six registers:

 

  • Watchdog Load Register: Holds the value which the watchdog timer counts down from. In auto-reload mode, the watchdog counter resets to the value stored in this register. Writes to this register will result in the watchdog counter register being reset to this value.
  • Watchdog Counter Register: This is the watchdog counter itself. It’s decrementing counter. Depending upon the watchdog mode, writing to this register reloads the counter. In watchdog mode, this register can only be updated by writing to the Watchdog Load Register.
  • Watchdog Control Register: This register controls the configuration of the watchdog (timer or watchdog), the pre-scaler setting, the interrupt enable, auto-reload mode, and the enabling of the watchdog in its currently configured mode.
  • Watchdog Interrupt Status Register: Contains a single event flag that shows when the counter has reached zero. Writing to this register resets it.
  • Watchdog Reset Status Register: This register contains a single bit that is only cleared by power-on reset (not a watchdog-triggered reset). It can also be cleared by a software application. The reset status bit allows the software to determine whether or not the reason for a reboot was caused by a watchdog timeout.
  • Watchdog Disable Register: This register requires two specific patterns to be written to it to enable the watchdog mode bit within the Watchdog Control Register when the watchdog is set to timer mode.

 

As we saw with the Zynq SoC’s private timer, the Zynq software-development environment provides a number of functions and macros that you can use to configure and drive the watchdog. These are included within

 

#include "xscuwdt.h"

 

This file enables the facilities to:

 

  • Test if the watchdog has expired
  • Load the watchdog
  • Start, stop, and restart the watchdog
  • Set the watchdog mode
  • Configure and initialize the watchdog

 

The following example configures the watchdog to operate as a traditional watchdog with no refresh so that the watchdog resets the Zynq SoC when it times out. The example code then checks to determine the cause of the reset following a watchdog reset (e.g. power-on reset or watchdog timeout) and reports this over STDOUT. Pressing the pushbutton starts the private timer, illuminates the LED, and starts the watchdog.

 

To do all of this, we follow a standard approach of configuring the watchdog as we have done for all of the peripherals to date using the data from xparameters.h and the configuration routines:

 

//define private watchdog

#define WDT_DEVICE_ID         XPAR_SCUWDT_0_DEVICE_ID

#define INTC_DEVICE_ID        XPAR_SCUGIC_SINGLE_DEVICE_ID

#define WDT_IRPT_INTR         XPAR_SCUWDT_INTR

#define WDT_LOAD_VALUE        0xFF

 

//watchdog configuration

 WCHConfigPtr = XScuWdt_LookupConfig(WDT_DEVICE_ID);

 XScuWdt_CfgInitialize(&WdtInstance, WCHConfigPtr,WCHConfigPtr->BaseAddr);

 XScuWdt_LoadWdt(&WdtInstance, WDT_LOAD_VALUE);

 XScuWdt_Start(&WdtInstance);

 

Following initialization and loading of the watchdog, the next steps are to enable the interrupt (within the interrupt configuration function) and to set the watchdog to the watchdog function as opposed to the timer function using the XScuWdt_SetWdMode() function:

 

//set up the watchdog

XScuGic_Connect(GicInstancePtr, WdtIntrId,(Xil_ExceptionHandler)WdtIntrHandler,

(void *)WdtInstancePtr);

 

//setup the watchdog

XScuWdt_SetWdMode(WdtInstancePtr);

 

Should we wish to use the watch dog in a timer mode instead we can call the function:

 

XScuWdt_SetTimerMode()

 

That is why I set up the interrupt to trigger on the watchdog running in timer mode and declared an empty interrupt service routine for the watchdog, which would be called in this instance.

 

We can use the function that reads the watchdog reset status register to see if the last reset was due to watchdog event:

 

XScuWdt_IsWdtExpired(InstancePtr)

 

The picture below show the results output over STDOUT when the processor is powered on from a power on reset and from the reset that occurs when the pushbutton is pressed to enable the watchdog timer:

 

 

Console STDOUT Part 16.jpg 

 

The previous reset state holds the state of the watchdog event stored within the watchdog reset status register accessed via XScuWdt_IsWdtExpired()

 

The source code for this example is attached to this blog post.

 

 

Please see the previous entries in this MicroZed series by Adam Taylor:

 

Implementing the Zynq SoC’s Private Timer: Adam Taylor’s MicroZed Chronicles Part 15

 

MicroZed Timers, Clocks and Watchdogs: Adam Taylor’s MicroZed Chronicles Part 14

 

More About MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 13

 

MicroZed Interrupts: Adam Taylor’s MicroZed Chronicles Part 12

 

Using the MicroZed Button for Input: Adam Taylor’s MicroZed Chronicles Part 11

 

Driving the Zynq SoC's GPIO: Adam Taylor’s MicroZed Chronicles Part 10

 

Meet the Zynq MIO: Adam Taylor’s MicroZed Chronicles Part 9

 

MicroZed XADC Software: Adam Taylor’s MicroZed Chronicles Part 8

 

Getting the XADC Running on the MicroZed: Adam Taylor’s MicroZed Chronicles Part 7

 

A Boot Loader for MicroZed. Adam Taylor’s MicroZed Chronicles, Part 6 

 

Figuring out the MicroZed Boot Loader – Adam Taylor’s MicroZed Chronicles, Part 5

 

Running your programs on the MicroZed – Adam Taylor’s MicroZed Chronicles, Part 4

 

Zynq and MicroZed say “Hello World”-- Adam Taylor’s MicroZed Chronicles, Part 3

 

Adam Taylor’s MicroZed Chronicles: Setting the SW Scene

 

Bringing up the Avnet MicroZed with Vivado

 

Comments
by Newbie duanl
on ‎04-17-2014 09:33 AM

Thank you so much for you great guiding!.

But where can I find the source code of this example?

by Xilinx Employee
on ‎04-17-2014 01:28 PM

duanl,

 

Adam Taylor sent the source code to me. It's attached as a Microsoft Word docx file to this post.

 

--Steve

 

by Explorer
on ‎07-20-2014 11:04 AM

hi

 

is it possible to run this demo on zedboard, with linx Os ? or it's an indepeding application ?

 

thank you

by Observer taylo_ap
on ‎07-21-2014 11:36 AM

gma-87

 

No this example is run on a bare metal system - I will be moving on to linux over the next few months once we have got uc/osiii and freeRTOS up and running 

 

Adam 

by Explorer
on ‎10-02-2014 03:34 PM
hi Adam, what about "wdtps.h" , what's the difference between this library and "xscuwdt.h"
by Observer taylo_ap
on ‎10-03-2014 12:08 PM

Hi GMA

 

The difference is a little subtile

 

scuwdt.h supports each cores private watchdog 

xwdtps.h supports the system watchdog 

 

Hope this helps 

 

Adam 

Labels
About the Author
  • Be sure to join the Xilinx LinkedIn group to get an update for every new Xcell Daily post! ******************** Steve Leibson is the Director of Strategic Marketing and Business Planning at Xilinx. He started as a system design engineer at HP in the early days of desktop computing, then switched to EDA at Cadnetix, and subsequently became a technical editor for EDN Magazine. He's served as Editor in Chief of EDN Magazine, Embedded Developers Journal, and Microprocessor Report. He has extensive experience in computing, microprocessors, microcontrollers, embedded systems design, design IP, EDA, and programmable logic.