Each module configures its own watchdog timeout and message processing budget with the CONFIG_APP_<MODULE>_WATCHDOG_TIMEOUT_SECONDS and CONFIG_APP_<MODULE>_MSG_PROCESSING_TIMEOUT_SECONDS options, sized after the longest operation the module performs while handling a message. The defaults, as watchdog timeout / processing budget, are:
| Module | PPP | nRF93M1 AT | nRF91 AT |
|---|---|---|---|
| Main | 30 s / 5 s | 300 s / 290 s | 300 s / 290 s |
| Network | 120 s / 110 s | 300 s / 290 s | 300 s / 290 s |
| Cloud | 300 s / 290 s | 120 s / 100 s | 300 s / 290 s |
| FOTA | 300 s / 290 s | Not included | Not included |
| Location | 120 s / 100 s | 150 s / 130 s | 300 s / 290 s |
| Battery | 60 s / 30 s | 30 s / 10 s | Not included |
The PPP Host Application uses the same timeouts on every board. Modules whose handlers make blocking calls get long timeouts. In the PPP Host Application, the Cloud and FOTA handlers make blocking CoAP calls. In the Cloud module a connect attempt performs a DTLS handshake, and the shadow, message, location, and remote debugging requests are blocking CoAP exchanges. In the FOTA module the poll makes reliable CoAP calls to check for and report a job; the image download itself does not block, because the module uses the nRF Cloud FOTA poll library in non-blocking mode and drives the download from its callbacks. The AT host applications size their timeouts the same way, after the operations their own modules perform. In the nRF91 AT Host Application, each provisioning step and each location attempt waits for a Serial Modem result URC, which can take minutes.
Modules that never block in their handlers only publish messages, drive the connection manager, or start asynchronous work, all of which return immediately while results arrive later as messages or callbacks. Their timeouts are short, sized only to catch a genuinely stuck thread rather than to cover a long operation. In the PPP Host Application, the Main module is such a module. Two others have longer budgets for one blocking case each:
- The Network module drives the connection manager, whose calls return immediately while results arrive later as events. The exception is bringing the interface down, where Zephyr's
modem_cellulardriver blocks the thread for up to 30 seconds while it suspends the modem. - The Location module has two backends. The Location library backend, used on the nRF54 hosts, starts an asynchronous Wi-Fi scan that returns immediately, with the result arriving later through a callback. The modem AT backend, used on the nRF93M1 DK, blocks on its cell and Wi-Fi scans. The timeouts cover the blocking backend, so they are the same on every board.