stm32CubeMx..........Most embedded programmers may be accustomed to using the stm32 library development method to implement functions. I have been using the library version v3.5.0 before. When I started using the stm32CubeMx development method, I found that it was very different from the original library development method and the implementation method was also different. This article aims to write down some of my experiences in the stm32CubeMx development method for your reference.
As for watchdogs, there are two types in stm32, namely independent watchdog (IWDG) and window watchdog (WWDG). Here we briefly introduce the two watchdogs. This article focuses on the window watchdog.
Independent watchdog: The independent watchdog (IWDG) is driven by a dedicated 40kHz low-speed clock and remains effective even if the main clock fails. IWDG is most suitable for applications that require the watchdog to work completely independently outside the main program and have low requirements for time accuracy.
Window watchdog: Window watchdog is usually used to monitor software failures caused by external interference or unforeseen logic conditions when the application deviates from the normal running sequence. In layman's terms, two resets will be generated. Reset conditions: (1) When the counter value decreases from 0x40 to 0x3F; (2) When the counter value is greater than the window upper limit when refreshing the watchdog. A reset signal can be generated if any of the conditions are met. Usually, the window upper limit is set to 0x7F, and the lower limit is 0x40 by default. When the counter counts down to 0x40, an interrupt will be generated. After the next 910us, when it becomes 0x3F, the system will be reset. In other words, the dog feeding operation cannot be done too early, that is, a reset will occur when it is greater than the window value; if it is fed too late, that is, the dog is not fed in time when the counter value decreases from 0x40 to 0x3F, a reset will also occur.
Experimental description: The board model is stm32F103VET6, and each time the dog is fed, it is printed out through the serial port
Let's take a look at the implementation of the window watchdog in stm32CubeMx.
1. Set the value in stm32cubemx
We set the frequency division factor to 8, the window value to 0x5f, the count value to 0x7f, and the default lower limit of the window to 0x40. And turn on the interrupt. After turning on the interrupt, the interrupt bit will be set to 1, as shown in the figure:
(2) Write the WWDG initialization function
void WWDG_Init(void)
{
__WWDG_CLK_ENABLE(); //Enable WWDG clock
MX_WWDG_Init(); //Call the system initialization function, that is, after we set the value in the graphical interface, the value we just set will be converted into code. Just call it directly in this function
__HAL_WWDG_CLEAR_FLAG(&hwwdg, WWDG_FLAG_EWIF); //Before enabling the interrupt, clear the interrupt flag
HAL_WWDG_Start_IT(&hwwdg); //Set the interrupt flag and enable the interrupt,
}
(3) Let's look at the interrupt function. There are some differences between the interrupt function processing and library development methods of cubemx.
/**
* @brief This function handles Window watchdog interrupt.
*/
void WWDG_IRQHandler(void)
{
/* USER CODE BEGIN WWDG_IRQn 0 */
/* USER CODE END WWDG_IRQn 0 */
HAL_WWDG_IRQHandler(&hwwdg);
/* USER CODE BEGIN WWDG_IRQn 1 */
/* USER CODE END WWDG_IRQn 1 */
}
We see that a function is called in its interrupt function, HAL_WWDG_IRQHandler(&hwwdg); Let's look at this function again. In this function, there appears a callback function that is unique to the cubemx method. When the interrupt is enabled and the interrupt flag is satisfied, this function will be called, and our operation will be implemented here.
void HAL_WWDG_IRQHandler(WWDG_HandleTypeDef *hwwdg)
{
/* Check if Early Wakeup Interrupt is enable */
if(__HAL_WWDG_GET_IT_SOURCE(hwwdg, WWDG_IT_EWI) != RESET)
{
/* Wheck if WWDG Early Wakeup Interrupt occurred */
if(__HAL_WWDG_GET_FLAG(hwwdg, WWDG_FL AG_EWIF ) != RESET)
{
/* Early Wakeup callback */
HAL_WWDG_WakeupCallback(hwwdg);
/* Change WWDG peripheral state */
hwwdg->State = HAL_WWDG_STATE_READY;
/* Clear the WWDG Early Wakeup flag */
__HAL_WWDG_CLEAR_FLAG(hwwdg, WWDG_FLAG_EWIF);
/* Process Unlocked */
__HAL_UNLOCK(hwwdg);
}
}
}
(4) Next, let's discuss the feeding time of the watchdog. It is easy to calculate that the maximum feeding time of the window watchdog in the stm32f103 series is only 58ms. In some programs, we don't need to feed the dog so intensively. So how to increase the feeding time? After collecting some methods on the Internet, I implemented a method to increase the feeding time of the watchdog based on a specific example: that is, make an additional counter in the interrupt function. If the counter does not reach the set value, the dog feeding operation is performed, and the set value is increased by 1. When the counter reaches the set value, the initial value of the feeding timer is not loaded. At this time, the watchdog timer will be reduced from 0x40 to 0x3F to generate a system reset. Using this method, the timing time can be extended to 58ms*the set value of the additional counter, and it is not a problem to set it for tens of seconds. When the count value is reached, if we clear the count value, the watchdog system will reset, so we only need to clear the count value regularly in the main function, which is to increase the feeding time in disguise. Let's take a look at the specific example:
Every time a watchdog interrupt is generated, the callback function is called. I do the following in the callback function:
/*****************************Watchdog callback function************************************/
void HAL_WWDG_WakeupCallback(WWDG_HandleTypeDef* hwwdg)
{
if(time <=50)
{
HAL_WWDG_Refresh(hwwdg, WWDG_CNT); //Feed the dog function
printf("Feed the dog\r\n"); //Print once every time the dog is fed, no actual effect
time++;
}
}
/**************************Some functions in the main function************************************/
while (1)
{
if(time > 50)
{
time = 0;
printf("time cleared\r\n");
}
}
I set the maximum watchdog feeding time to 58ms, so counting 50 times is about 2.9s, which means I must clear the counter within 2.9s in the main function, and the system will not reset as long as the counter is cleared. Correspondingly, the count value can be set larger, which depends on personal needs. Is this a disguised way to increase the feeding time?
Here is my serial port printing effect:
Let's take a look and see if "Feed the dog" is printed every time the dog is fed. At the same time, the time is reset to zero at 11:55:20 and again at 11:55:23. Is the interval about 3 seconds?
Well, I have just started using stm32CubeMx development. If there are any problems in the content, I hope you can point them out and make progress together.
Previous article:STM32 watchdog IWDG WWDG
Next article:How to implement a window watchdog using Stm32CubeMX and LL library
- Popular Resources
- Popular amplifiers
- Learn ARM development(16)
- Learn ARM development(17)
- Learn ARM development(18)
- Embedded system debugging simulation tool
- A small question that has been bothering me recently has finally been solved~~
- Learn ARM development (1)
- Learn ARM development (2)
- Learn ARM development (4)
- Learn ARM development (6)
Professor at Beihang University, dedicated to promoting microcontrollers and embedded systems for over 20 years.
- LED chemical incompatibility test to see which chemicals LEDs can be used with
- Application of ARM9 hardware coprocessor on WinCE embedded motherboard
- What are the key points for selecting rotor flowmeter?
- LM317 high power charger circuit
- A brief analysis of Embest's application and development of embedded medical devices
- Single-phase RC protection circuit
- stm32 PVD programmable voltage monitor
- Introduction and measurement of edge trigger and level trigger of 51 single chip microcomputer
- Improved design of Linux system software shell protection technology
- What to do if the ABB robot protection device stops
- Analysis of the information security mechanism of AUTOSAR, the automotive embedded software framework
- Brief Analysis of Automotive Ethernet Test Content and Test Methods
- How haptic technology can enhance driving safety
- Let’s talk about the “Three Musketeers” of radar in autonomous driving
- Why software-defined vehicles transform cars from tools into living spaces
- How Lucid is overtaking Tesla with smaller motors
- Wi-Fi 8 specification is on the way: 2.4/5/6GHz triple-band operation
- Wi-Fi 8 specification is on the way: 2.4/5/6GHz triple-band operation
- Vietnam's chip packaging and testing business is growing, and supply-side fragmentation is splitting the market
- Vietnam's chip packaging and testing business is growing, and supply-side fragmentation is splitting the market
- Development board CC3200-LAUNCHXL,
- TMS320F28335 Study Notes——DMA
- RISC-V MCU Development (Part 2): Project Creation and Management
- What is this DC to AC circuit called a power supply circuit?
- MSP430 analog-to-digital conversion module--ADC12
- TPA3245 series amplifier problem
- EEWORLD University Hall----Live Replay: Application of TI Sitara? Products in Smart Grid
- So cool! Flexible screen concept smart watch
- A chart shows how 5G is better than 4G, with a challenge
- How does FPGA adjust the volume of the buzzer?