ST7FLITE2 watchdog timing

[fggnrc]

Posted on January 07, 2005 at 08:23

ST7FLITE2 watchdog timing

[fggnrc]

Posted on January 02, 2005 at 02:09

Happy new year to everybody!

In my hobbyist project, the zero-crossing of the mains frequency (50Hz) has two uses: 1) to continuously adjust the internal RC oscillator (more stable frequency on a wider range of temperatures) 2) to ''fire'' the control loop every 10 ms. The latter implies that the control loop should take at most 10 ms in every condition. For this reason, I am planning to use the watchdog timer with a 10 ms timeout which satisfies the one-page EEPROM programming time too. When I browsed the ST7FLITE2x watchdog description (pages 51-54 of the last datasheet), I wasn’t able to explain the column “min“ of Table 12 (Watchdog timing). I realize that the watchdog prescaler value is unknown when WDGCR is refreshed, and that the exact watchdog timeout is thus a random value. I know also that every 2 ms (= 0.125us * 16.000 @8MHz) the watchdog counter is decremented, but I can not explain the 1 ms entry. Suppose that the micro writes $C0 into WDGCR a clock cycle before it is decremented (i.e. the prescaler value is 15999). In this situation after a clock cycle, T6 becomes clear and a reset is generated. According to my reasoning the minimum watchdog timeout is therefore 0.125 us and not 1 ms! What is wrong in my calculations? To be sure that the control loop takes at most 10 ms, what value I have to use $C4 or $C5? Thanks in advance, EtaPhi

[wolfgang2399]

Posted on January 03, 2005 at 09:25

Hi EtaPhi,

quite a strange usage of the watchdog timer... Please could you give me any feedback out of your experiences: - What happens with the PLL/RC oscillator accuracy after reset during PLL Stabilization time (up to 4ms)? I can hardly imagine how to adjust the RC oscillator with the wdg timer. Why won't you use the timebase counter 1 of the Lite Timer 2 which seams to be predestinate to your application? I take at for my internal timebase (2ms, 10ms, 1s, 1h) To measure the accuracy of the RC oscillator I would prefer to take the time of about 10 zero crossing events. Best way in my opinion is to use the Input Capure Register of the free running counter e.g. of the 8-bit timebase counter 1 with the LTIC input port. I completely agree with you to the description of the minimum/maximum time of the watchdog counter. Best regards WoRo

[fggnrc]

Posted on January 05, 2005 at 02:01

Hello WoRo!

I am really pushing the ST7FLITE29 to its limits... To reduce costs and components, there is no external crystal. The internal RC oscillator have to be as much stable as possible because it provides the base-time for a software RS-485 communication link. The 1% precision of the RC oscillator helps, but when the temperature drops below 0°C, a 5% frequency shift may happen. This is a problem for a software SCI, since a start bit + 8 bits + parity + a stop bit can yield more than 50% of error when sampling (and transmitting) a bit. I consider such extreme conditions, because my project is a device for home automation that may be used outside in a cold winter or in a hot summer while it talks to similar indoor devices. The user will have 4 inputs (analogue or digital) and 4 outputs (analogue or digital). The 12-Bit Auto-reload Timer is dedicated to those PWM outputs @ 2 kHz (the maximum resolution available @ 8 MHz). To have an analogue output, the PWM output will be filtered by a low-pass RC network. The software SCI uses the 8 bit Auto-Reload Timer and some tricks to keep the receive synchronization error as small as possible (about 4 us). Even if the PWM outputs do not allow me to follow the AN 1753 (Software UART using ST7 12-Bit Auto-reload Timer), I still use the 12-Bit Auto-reload Timer to detect the communication time-outs. To control the RC oscillator frequency, the choice is between two input capture pins: LTIC (connected to the 8-Bit Time-base Counter) and ATIC (connected to the 12-Bit Auto-reload Timer). I choose the former because no race condition may happen when I read its value, and because the 4us resolution is good enough to measure a zero crossing. You are right when you suggest to use the mean value of some zero crossing events. The 3rd (150 Hz) and 5th (250 Hz) harmonics are often so strong (I measured a 20 dB gap from the fundamental harmonic), that the simplest way (and cheapest one) is to use a digital filter (i.e. to use the mean value). In my application I use 8 samples. This choice brings in a delay of about 80 ms. 16 samples would be better, but overflows may happen in the two bytes accumulation (10 ms = $9C4 ticks @ 4us). This solution is ok for thermal drifts and requires only three shifts to compute the mean value. Then a simple software PI (proportional-integral) controller adjusts the RCCR value. The mains frequency, beside keeping all synchronised, has another use: the input capture event “fires� the PLC loop. For this reason and to be sure that no PLC loop is overrun by the previous one, I want to use the watchdog with a 10 ms timeout (i.e. the zero crossing). If I write $C4 to WDCR, the PLC loop may take at most 8 ms to run (according to my calculations), because of the most stringent condition. This means an idle time of about 20% in the worst conditions (i.e. heavy RS-485 communication). If the same value allowed for a 9 ms timeout (as the datasheet suggests), the safety requirements would be simpler to meet. Perhaps I missed some important things in my explanation, since I use almost every ST7LITE29 feature (I plan to use the SPI to expand the digital I/O when no analogue input is needed), every clock cycle, every EPROM byte and every I/O pin to create a complex application which will be cheap and, probably, in the public domain… Thanks WoRo for your clues, EtaPhi

[wolfgang2399]

Posted on January 05, 2005 at 06:57

Hi EtaPhi,

seems to be a well sophisticated application and not so easy for me to understand all the points of your sollution. I hardly can see, how to measure time while using the watchdog timer. However... You say: 16 samples would be better, but overflows may happen in the two bytes accumulation (10 ms = $9C4 ticks @ 4us). --> 16 samples of $9C4 gives $9C40 but no overflow. Good results to your project! WoRo

[fggnrc]

Posted on January 07, 2005 at 01:49

$9C4 is the reference value, i.e. the value measured when the RC oscillator is locked to a 50Hz sinewave.

The no overflow condition must hold ALWAYS to control the RC oscillator frequency. The worst condition happens when RCCR = $00, i.e. the ST7FLITE29 is ''overclocked''. According to the datasheet (figure 56 at page 97), the maximum RC oscillator frequency is about 1.6 MHz. Therefore the maximum result is $FA0 (4000 cycles @ 2.5 us). This value could allow 16 samples, but this may be not true since my calculations do not consider the mains noise. My application uses a 12 VAC line to power the devices. This voltage is provided by a small transformer whose magnetic hysteresis brings in a big 3rd and 5th harmonics noise. I saw this 50 Hz signal with the oscilloscope and measured a semi-period between 9 and 11 ms. Their sum is obviously 20 ms, so a 16 samples mean would be ok, but I prefer to be sure that no overflow could ever happen. As regards the watchdog timer, the PLL stabilization time is not a issue because I use a software watchdog. There is a big difference with hardware and software watchdogs: the former is always active, the latter becomes active AFTER the first write to WDGCR. Therefore I activate it only after the initialization (stabilization) step and touch it only at the beginning of the PLC loop: NoZC LD A,#WDG_TIME LD WDGCR,A SCHEDULER WaitZC BTJF LTCSR1,#ICF,NoZC ; Some more PLC code follows JP WaitZC ; End of PLC Loop where SCHEDULER is a macro that yelds the CPU to the other (concurrent) tasks. When WDG_TIME = $C4, I am sure that the PLC loop takes at most 8 ms to be executed (otherwise the watchdog will bark...) EtaPhi

Code:

[wolfgang2399]

Posted on January 07, 2005 at 08:23

Hi EtaPhi,

just for your studies: attached to this message is a modified part of an application with a ST72 Anyway, I think the main information will be recognisable easily. I took the very part in my application to measure a frequency of about 500Hz with good accuracy - but I suppose it might fit to your request as well. Best regards WoRo ________________ Attachments : Sample_01.txt : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I06C&d=%2Fa%2F0X0000000bU7%2FheDpTNdLes1lpkOUj9PPyTkX2mq4N_aIu7dUokYgcPk&asPdf=false