STM32L4 + Cellular Modem: IWDG vs Long Blocking Operations Dilemma

[GR88_gregni]

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:

• Hardware: STM32L4 custom board with cellular modem (Quectel BG95/BG96)
• Communication: UART-based AT commands with IDLE line interrupt (no DMA)
• Application: Periodic sensor data transmission to server via UDP
• Power Management: Device enters STOP2 mode between measurement cycles

IWDG Configuration:

• Clock Source: LSI (32kHz)
• Timeout: ~32.8 seconds maximum (IWDG_PRESCALER_256, Reload=4095)
• Behavior: Once enabled, cannot be disabled; pauses during STOP modes

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:

• Network Time Protocol (NTP) synchronization: Up to 125 seconds
• Network registration in poor coverage: Up to 60 seconds

Currently, IWDG triggers reset during these legitimate operations, causing communication failures.

Questions for the Community:

1. Error Masking Concern: If I add HAL_IWDG_Refresh(&hiwdg) inside the timeout loop every 25 seconds, could this mask genuine errors? For example, if strstr() encounters issues, or if the system enters an unexpected state but continues looping?
2. Architecture Recommendations: What's the best practice for handling this scenario?
   1. Implement progress-based IWDG refresh (only refresh when receiving data)?
3. Real-World Experience: For those working with cellular IoT applications, how do you balance IWDG protection with legitimate long network operations?
4. Debugging Implications: If I implement periodic IWDG refresh, what debugging strategies would you recommend to ensure I'm not masking critical issues?

Current Timeout Examples:

• Standard AT commands: 300-5000ms
• Network registration: 60,000ms
• NTP time sync: 125,000ms
• Modem initialization: 30,000ms

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

[Andrew Neil]

1. Don't use blocking delays.
    
2. If you really must use blocking delays, divide them into "chunks" of less than the IWDG timeout.