Cinterion
®
Java Terminal Hardware Interface Description
8.1 Reset Conditions
90
PLS62T-W_HID_v01 2018-06-20
Confidential / Prelimenary
Page 64 of 91
8.1 Reset Conditions
The watchdog implements three conditions, under which a reset of the module is automatically
performed:
• Repetitive: A module reset is performed frequently and repetitive. This reset condition can
be used to force the module to reconnect to the mobile network once in a while. Typical fre-
quencies can be 24h or longer. This feature can be configured via the RST_REP timeout.
• UART activity: The watchdog can be used to reset the module, when no response from the
module on AT commands is recognized for a specified amount of time. To prevent the reset,
the module has to be active frequently on the UART interface. This reset condition can be
configured via the RST_UART timeout, it is deactivated when timeout parameter = 0.
• GPIO activity: The watchdog can be used to reset the module, when no activity on the des-
ignated GPIO signal is recognized for a specified amount of time. To prevent the reset, the
module has to be active frequently by toggling this GPIO signal. This reset condition can be
configured via the RST_GPIO timeout, it is deactivated when timeout parameter = 0.
When the watchdog is enabled, it will observe the activities on the UART and GPIO interfaces
as well as the Java module status, depending on timeout parameter settings and perform fre-
quent resets, if it is configured to do so.
8.1.1 Reset stages
Basically, there are up to two escalation stages during a module reset:
• First stage (regular fast shutdown): The watchdog shuts down the module via an internal
fast shutdown signal. The fast shutdown procedure will then still finish any data activities on
the Java module's flash file system, thus ensuring data integrity, but will no longer deregis-
ter gracefully from the network, thus saving the time required for network deregistration.
Afterwards, i.e. after an internal signaling has gone low, the module is regularly restarted.
• Second stage (emergency restart): If the module can for some reasons not be switched off
successfully during the first stage, the watchdog resets the module via an internal
EMERG_RST signal. The emergency restart procedure includes disconnecting the power
supply lines, and causes the loss of all information stored in the Java module‘s volatile
memory.
During the first stage the watchdog waits for up to three seconds for the internal signaling to go
low. If the internal signaling does not change, the watchdog escalates to the second stage in
order to switch off and restart the module.
The watchdog can also be configured to automatically switch on resp. power up the module
following a shutdown and a configured delay time (always-on mode).
To Next Page
Loading...
Need help?
General