2025-08-07 1:09 AM
Hello STM32 Community,
I'm developing a cellular IoT device using STM32L4 and facing an architectural challenge regarding IWDG implementation with long cellular communication timeouts. I'd appreciate your expertise and recommendations.
System Overview:
IWDG Configuration:
The Challenge: My low-level AT command function implements timeout-based communication to prevent infinite loops:
int <function_name>(const char *command, const char *expected_response,
/* other params */, int timeout_ms) {
uint32_t start_time = HAL_GetTick();
// Send AT command via UART
while ((HAL_GetTick() - start_time) < timeout_ms) {
if (rx_data_ready_flag) {
// Copy UART response to buffer
// Check for expected response patterns
}
if (strstr(response_buffer, expected_response)) {
// Parse response and return success
break;
}
// Handle error responses, retries, etc.
}
return result;
}
The Problem: Some legitimate cellular operations require timeouts exceeding IWDG maximum:
Currently, IWDG triggers reset during these legitimate operations, causing communication failures.
Questions for the Community:
Current Timeout Examples:
The system works reliably when IWDG is disabled during development, but I need it enabled for production deployment to handle potential firmware hangs, memory corruption, or hardware issues. The device operates in remote locations where manual recovery isn't feasible, making robust watchdog implementation critical. However, cellular connectivity can be unpredictable, and legitimate operations sometimes require extended timeouts.
Any insights, experiences, or architectural recommendations would be greatly appreciated!
Best regards,
NG
2025-08-07 2:18 AM
2025-08-07 2:57 AM
I am using a state machine that handles the communication process with the modem. The blocking delays are necessary because if the modem doesn't successfully obtain an IPv4/IPv6 address, the system cannot proceed to the next step.
Regarding chunking the timeouts: The modem genuinely requires up to 60 seconds for successful network connection, and up to 125 seconds for NTP synchronization. If I were to chunk these operations with my current implementation, I would need to:
Split the 60-second timeout into two 30-second calls Split the 125-second timeout into four 31-second calls
However, this approach has a significant drawback: if the first chunk times out, I need to ensure the low-level function continues listening for the response rather than giving up. This would require substantial code restructuring and make the implementation much more complex and less readable.
That's why I'm asking: if I simply refresh the IWDG counter inside the existing blocking delay (within the while (timeout) loop), could this potentially mask errors that would otherwise cause the MCU to reset? My primary goal is to prevent the MCU from getting stuck while still allowing legitimate long operations to complete.
In other words, I want to ensure I'm not trading IWDG timeout issues for the risk of masking genuine system failures.
2025-08-07 3:26 AM
Using a State Machine should make it easy to use non-blocking delays!
@GR88_gregni wrote:The blocking delays are necessary because if the modem doesn't successfully obtain an IPv4/IPv6 address, the system cannot proceed to the next step.
That doesn't follow at all - that can certainly be handled without blocking delays.
@GR88_gregni wrote:if the first chunk times out, I need to ensure the low-level function continues listening for the response rather than giving up. This would require substantial code restructuring and make the implementation much more complex and less readable.
It shouldn't do; eg,
while ((HAL_GetTick() - start_time) < timeout_ms) {
if (rx_data_ready_flag) {
// Copy UART response to buffer
// Check for expected response patterns
}
if (strstr(response_buffer, expected_response)) {
// Parse response and return success
break;
}
if( time_to_update_wd() )
{
// Update the WD
}
// Handle error responses, retries, etc.
}