2017-02-23 04:04 AM
Hello,
We are developing a PV converter and we have choose an STM32F407VGT microcontroller in order to controlling its power electronics and communications.
We are using the
♯
in order to ensuring that the software works properly and if not reset the system and initialize in a safe state. Mainly stopping the PWM modules and stop triggering the Mosfets. We would like configuring the IWDG at minimum period (125us). We carries out the IWDG reset in a timer (TIM2) update event interrupt each 50us. For reseting de WDG we are using the HAL function HAL_IWDG_Refresh(&hiwdg). Following is the IWDG initialization code:hiwdg.Instance = IWDG;
hiwdg.Init.Prescaler = IWDG_PRESCALER_4;
hiwdg.Init.Reload = 0;
if (HAL_IWDG_Init(&hiwdg) != HAL_OK)
{
Error_Handler();
}
We have tested 3 different values for hiwdg.Init.Reload, 0, 1, and 2. If we use 0 or 1 the systems restarts continuously. If we use 2 the watchdog works, but four application the watching time is too long and produce that some converter components could explode. How can we configuring the IWGD in order to having a WD period of 125us as told in the manual reference?
#iwdg #stm-32 #stm32f407 #problem2017-02-23 04:27 AM
We carries out the IWDG reset in a timer (TIM2) update event interrupt each 50us.
Putting apart the question whether it's a good idea to kick the dog in an interrupt, are you sure it happens *every* 50us? Can you toggle an output an observe it using a logic analyzer, instead of kicking the dog?
JW
2017-02-23 05:32 AM
,
,
Yes we did it. The kick happens each 50 us we are monitoring the interrupt code with a GPIO.
De: waclawek.jan
Enviado el: jueves, 23 de febrero de 2017 13:29
Para: Rubén Acerete Halli <,racerete@fcirce.es>,
Asunto: Re: - Re: IWDG short period (125 us) problem
<,https://community.st.com/?et=watches.email.thread>, STMicroelectronics Community
Re: IWDG short period (125 us) problem
reply from waclawek.jan <,https://community.st.com/0D70X000006STu4SAG
2017-02-23 06:00 AM
I'm not an expert in this field, but turning off H-bridges via watchdog (IWDG) seems not feasible to me.
Proper motor control (H-bridge control) driver peripherals use to have an emergency shutoff feature, with nanoseconds reaction time.
You never get at that level with software or interrupts.
2017-02-23 07:32 AM
I could be agree with you but for as if the IWDG works with 125us will be suitable and does not need additional external hardware. From de point of view of cost and space for our application it is important. Which you are proposing requires an external circuit.
2017-02-23 07:47 AM
Wait, what? You're strobing the watchdog in a timer interrupt? That is exactly the situation that should never be used for a watchdog.
A watchdog is intended to reset the processor when your code screws up. So if your code is off doing something unexpected (infinite loop), the watchdog will fire and reset your processor.
If you put the strobe of the watchdog into a timer interrupt, your code can be completely broken and the timer will continue to tick, right on time since it is hardware, and the interrupt will fire and the watchdog will get cleared. EVEN THOUGH YOUR CODE IS BORKED!
A safer method is, in your super loop, do all of your calculations and finally strobe the watchdog. If any of your calculations cause the processor to miss its deadline, the processor gets reset.
The IWDG is a safety device to reset your processor, not to keep it running.
Second, the IWDG is based on an oscillator that has very poor frequency control. Not only is it 32000Hz, but it is 32768Hz, and 40000Hz, all at the same time. One of your machines may work correctly, but another will reset, just due to the variation in the oscillator. The 'I' in IWDG indicates that it runs independently of the rest of the processor, they don't share oscillators. That way the IWDG cannot get into lockstep with the processor and if there is a clock chain failure (due to executing data and reprogramming the clocks) the IWDG will still be able to reset the processor.
2017-02-23 08:55 AM
The hardware (motor control peripheral of the MCU) must have such an emergency-shutoff feature.
From de point of view of cost and space for our application it is important. Which you are proposing requires an external circuit.
To be brutally honest - then you get what you deserve. Software cannot do everything.
I have seen several device prototypes blowing up because of exactly such decisions by project management and / or HW design. But you are free to try, anyway.
2017-02-23 09:24 AM
The real system is not so simple as I told in my previous explanation because there is a software mechanism that ensure that the rest of the code less priority than the interruption is working. Apart from the right use or not of the IWGD in my application, my real problem is that I resets the IWDG each 50us and when the IWDG period is configured at 125us and 250us seems that the watchdog reset does not works and the system restart. I am reseting the WD at the double of frequency than it works. I does not think that the internal clock could varies enough
to reach 80 kHz.Furthermore I have just test to reseting the watchdog in the main loop with no more code something similar that:
int main(void){
hiwdg.Instance = IWDG;
hiwdg.Init.Prescaler = IWDG_PRESCALER_4;
hiwdg.Init.Reload = 0;
if (HAL_IWDG_Init(&hiwdg) != HAL_OK)
{
Error_Handler();
}
while (1)
{
HAL_IWDG_Refresh(&hiwdg);
}
}
It does not work. How can I configuring the IWGD for running as fast as possible?
2017-02-23 09:33 AM
What do you mean by 'it does not work'?
For such a minimal code, couldn't you simply drop Cube and write directly to registers?
JW
2017-02-23 09:45 AM
I mean that I spect that the reset counter will be reset in the main loop so fast that the IWDG never reset my system, but by contrast the system restarts.
I am going to try accesing de register directly but I think that the result will not change.