Hello,
How do I use the Watchdog counter in a Sigma300/350 processor?
Hello,
How do I use the Watchdog counter in a Sigma300/350 processor?
First let me say that many customers use a GPIO with a counter to create a heartbeat that can be monitored by an external controller. This is certainly one way to do this.
The Watchdog Counter function is not to be confused with the PLL Watchdog. That is a different feature and I will not cover that here.
At this point in time the Watchdog counter will not be automatically reset by the framework code in SigmaStudio. So this must be done in the SigmaStudio Schematic and it is easy to do.
The Watchdog does not have an enable/disable register. There are only two control registers, the Prescaler (0xF444) and the MAXCOUNT (0xF443) registers.
Then there is the Watchdog Panic Code Mask and the actual Watchdog Panic Code flag registers. There are no other registers associated with the Watchdog counter.
If the program is loaded from a DSP reset, AND the MAXCOUNT = 0. The Watchdog counter feature will be disabled.
To enable the Watchdog counter, you do one of these two things:
Once enabled it functions in this way:
The prescale counter will increment every CORE clock cycle and once it reaches the prescale setting of clock cycles it will decrement the Watchdog counter. So if the Prescaler is set to 64, then it will decrement the Watchdog counter every 64 CORE clock cycles.
The Watchdog will continue to be decremented and if it reaches zero, it will set the Watchdog Panic Code Flag. It will continue to set this flag every time it is attempted to be decremented once it has reached zero. In other words, it will not wrap around to 0xFFFFF and start counting over. Once it trips it will stay at zero until it is reset.
So how is the counter reset?
Writing to MAXCOUNT register will set an internal flag that will cause the Watchdog counter to be reset with the value in MAXCOUNT register. So this is the update mechanism. It is assumed that the MAXVALUE being used will not change but that does not matter. The act of writing to this register will trigger the update of the counter during the next core clock cycle.
So the SigmaStudio program I attached will update the Watchdog Max Count register during every sample frame thereby updating the Watchdog and preventing it from reaching zero. Should the program stop running then it will reach zero and trip the panic code flag. Note, that if the Start Pulse is externally generated, it is possible that if that clock source went away for a period of time the Watchdog would trigger since the code that updates the counter will not be running but the core clock is still running.
In my program I have a switch that allowed me to trigger the error. So here are the calculations:
I have the prescaler set to 64. Core clock is 294.912 MHz.
So 294,912,000 / 64 = 4,608,000. This is the number of times the Watchdog counter will be decremented in a second.
I am running at 48kHz sampling rate so this means that the counter will be decremented 96 times per sample period.
So the MAXCOUNT that is greater than 96 should not trigger the panic code. I used the maximum number of 8,192 just because that is what I was using earlier. If the start pulse is externally generated then I would have at least a small margin so that the jitter/drift of the sample rate would not cause a trigger. So a number of around 500 would mean that the program would have to hang for over five sample periods to trigger the panic code.
In the example program I have a switch to select a “1” as the MAXCOUNT value which will set off the panic code for testing purposes.
Now this brings up the Panic Code system which is another discussion. This can be polled by a controller or it can be tied to a GPIO pin which can be tied to an interrupt driven GPIO pin on the controller to automate this without polling.
Dave T
ADAU1452 Basic Stereo Input-Vol-Meter-Mute-with Watchdog reset.zip
Hello Meeh,
The values you are using may be too close to triggering the flag. In the case I used in the post the counter was decremented 96 times in ONE sample rate frame. In my example I am setting the counter to 0x61 which is 97. right on the bleeding edge of tripping!! If you are using a start pulse from an external source it may trip just from clock drift!
Now, in your case you are using SPI. You will never be able to write to a register using SPI EVERY sample period!! It is just too slow. So you need to set the prescaler fairly high and the MAXCOUNT register also fairly high to give you time to reset it via SPI. Sure, you may go for more than one frame before it trips but it will give you time to trip.
The MAXCOUNT register is only 12 bits. So the max is 4095. But, you also have a lot of leeway in the pre-scaler settings:
So analyze the SPI timing you are using, the clock speed and the address bytes you have to send so you know the timing of the SPI messages. Then setup the Watchdog to a longer time.
I think the correct way to do this is the way I did it in the example. Let the DSP do it itself. If something screws up it will flag the CPU. Why tie up the CPU with kicking the dog?
Do you need some other protection like if the CPU stops running you want the audio to mute or something? Or a tone to come out?
Then this is a different problem and would really need to be done differently. An internal timer to switch a MUX to mute the audio or switch to a tone. Setup the counter to count down and if it reaches zero then switch a signal... Hmmm.... I would have to think about this a little more. There should be a clever way to do this. There is usually many ways to do something in SigmaStudio!
Dave T
