Commonly seen Device logs/errors
Table of Contents
This article shows a list of commonly seen debug log messages sent by devices. They can be viewed here - View Device Logs. By default, "Severe" logs are recorded by the device and uploaded to the server.
Not every log indicates a problem, sometimes it is just an event that we feel is useful to record. An example would be a few logs showing connection errors are worth logging, but might just indicate the device was out of coverage for a little bit, and not an error/issue.
Some logs might point to a problem. The logging level can be changed like so - Turn on Debug Logging - to provide more detailed logging information.
Log Reason | Explanation | Solution |
---|---|---|
Debug[COM][Sevr]: Invalid command received | Issue communicating with Bluetooth module, Bluetooth® module shuts down, no other effect on device operation | Try upgrading your Bluetooth® firmware and device firmware to the latest versions for compatibility |
Debug[COM][Crit]: Unsupported BLE version 0001024E. Turning off. | The Bluetooth® firmware is not compatible with the current device firmware | Try upgrading your bluetooth firmware and device firmware to the latest versions for compatibility |
Debug[GEN][Crit]: VBat = 6124 mV, Reset = 0X4, Watchdog = 0X1 | This is the Battery voltage and if there's a Reset reason the code is detailed here | For Common reset reasons, see below If you are seeing RESET = 0x14, change batteries as soon as possible. |
[GSM][Sevr]: Aborting oneshot reg | Device can't register onto cellular network If the unit has been connecting before it generally just indicates a coverage issue at the time of the log. Or you have set your registration timeout too short in the Upload Parameters |
In most cases no action required. The device will report these logs when it's been out of coverage and unable to register. |
[GSM][Sevr]: Aborting oneshot data | Device could register on the network, but the upload failed. | Generally coverage related and intermittent. Could be a server issue if on a 3rd party server (server closing connection during upload) |
Debug[GSM][Sevr]: Hard Error: `AT` (0/3), LastRx: `` ![]() |
Modem is not responding after initial startup. The device resets the modem. This can happen on devices which use the SARA Modem intermittently. |
Part of normal device operation. No action required. If there are many of these logs consistently, it may point to a signal/device issue |
[GSM][Sevr]: Hard reset | The device has hard reset the modem. Can occur after the Hard Error above (in order to recover from the modem error) |
Update device to latest firmware. Modem error recover better handled in latest versions Underlying issues may be poor reception, too tight system parameters for modem |
[GSM][Sevr]: Modem turn off failed | Device unable to shut down modem because modem is busy/mid-operation |
Update devices to latest firmware. Modem shutdown better handled in latest versions. |
Hard Power Down
|
The modem was not responding, so the firmware reset it in order to recover back to normal operation | No action required. Points to an issue occurring during data upload. If there are many of these logs occuring regularly, it may point to a signal/device issue |
[GSM][Sevr]: Socket leak detected | Modem did not close connection properly | Generally intermittent and no action required. This is fixed by either a soft reset or a hard reset and is generated from a modem bug in the uBlox module |
Debug[GSM][Sevr]: Doing EMERG_OFF | When the unit shuts down, it instructs the modem to turn off before removing the power. If the Modem module takes too long to shut down, it gets forced off. | No issue, regular operation. |
Timeout Waiting for CTS | The cellular modem is not responding These logs will not appear in OEM, since if the modem can't respond, the device can't upload data. It indicates a fault with the modem. These faults would be seen if you are reading the logs via the Wired Provisioning Tool |
Replace the device. |
Debug[GSM][Sevr]: HTTP fail online-live2.services.u-blox.com:80 0/0 | Device has not been able to download GPS Aiding data from uBlox Generally due to a connectivity issue |
See 4G connectivity troubleshooting article here |
Debug[GSM][Info]: APN xyz,, Debug[GSM][Info]: Exhausted APNs xyz,, |
the device has an APN set to connect to the network. The modem has tried to use this APN and could not get online | Generally - no issue, this is the correct operation, it shows that the modem has been prevented from joining the 'wrong' network - particularly with roaming SIMS which may try join the wrong one. |
Debug[ACC][Crit]: Tumbler triggered cos^2<0 | Accident detected | Happens when the device has a sudden change in velocity or change in angle |
Debug[ACC][Crit]: Accel error in State_Cfg | Device cannot talk to Accelerometer module | If there are continous error logs, this suggests a hardware fault. Replace device. |
Debug[GEN][Sevr]: JAMW | GPS Jamming or Interference detected | See GPS Jamming and Interference Detection : Digital Matter Support |
Modem Freeze Reason |
Seen on devices using Nordic Modem | Occurs when the device is in certain locations with poor coverage. Device will recover when it gets back to coverage. Update to latest FW and modem versions |
GPS Error Hold Off! | Occurs on devices with the Sony GNSS - when the firmware is waiting for the module to turn off, but it continues to send sentences. The firmware simply shuts off the GNSS and logs this message |
No action required - logs should be sporadic and device will recover. If they are occuring constantly there may be a device issue requiring it to be changed over. |
Debug[GPS][Info]: Bad length: NMEA/PMTK: SGNRMC, 031855.40$PMTK011,MTKGPS*08 .000,A,D*57 7 | This log occurs when the device is switching between the binary and NMEA formats as there is often no assurance of sentence completion during the switchoever process. | This log should not prevent the device from obtaining a GPS fix, however it's advisable to update the device to the latest firmware version. |
Debug[GSM][Warn] Soft Error: `AT+CPIN?` (9/9), LastRx: ` ERROR ` |
The device SIM pin command to the SIM failed. This is usually due to the SIM not being inserted properly, but can also occur if a SIM has a unique user set pin. | Checking the SIM installation will usually fix this issue. Ensure the SIM is oriented the right way, and that the holder is properly closed for micro form factor SIMs. |
Commonly Seen Reset Logs
When a device resets, you will typically see a log such as the one below:
Debug[GEN][Crit]: VBat = 4888 mV, Reset = 0X4, Watchdog = 0x1
There are two values that are of interest here - the reset and watchdog reset reasons. The reset reasons tell you what kind of reset occurred - typically either a power on, brownout, or a firmware initiated reset. If the firmware initiated the reset, then the watchdog reason will tell you why.
Reset Reasons
The following are the most common reset reasons:
Reset Reason | Explanation | Applicable Devices |
0x1 | Power on reset. This mainly occurs when power is first supplied. It can also occur during severe brownouts. | All DM devices. |
0x2 | Brown out reset. The voltage dipped below the brown out threshold. Typically seen when batteries are depleted. Battery insertions can also appear as brownouts occasionally. | All DM devices. |
0x4 | Watchdog reset. The firmware reset the device. The reason it did so is detailed by the watchdog reset reason. | All DM devices |
0x10/0x14 | Under voltage lockout reset. The voltage dipped below the minimum voltage threshold. Typically seen when batteries are getting low. | Battery powered devices. |
Reset=2/Reset=6 | Under voltage lockout (UVLO) reset. Seen on devices using Nordic modem. The voltage dipped below the minimum operating voltage threshold. | Battery powered devices |
0xA | Reset from Provisioning Tool | All DM devices |
0xC | Brown out reset | All DM devices |
0x8 | Power on reset & brown out | All DM devices |
0x110/0x101 | Indicative of flash issues. 0x101 being an issue reading the flash, and 0x110 being an issue powering the flash. | All DM devices |
Watchdog Reset Reasons
Watchdog reasons less than 0x100 are manually initiated resets, whilst watchdog resets greater than or equal to 0x100 are caused by the device resetting itself to try and rectify an error state. The watchdog reasons greater than 0x100 tend to be device specific and are far less frequent so are not included here for brevity.
Remora3 4G, Oyster3 4G, Yabby3 4G, Hawk Cellular
Watchdog Reset Reason | Explanation |
0x0 | Either not a watchdog reset, or an unknown error occurred. |
0x1 |
App reset. This occurs when the device resets itself due to changed conditions. Typical reasons include:
|
0x2 | No comms. The device could not communicate with the server for 3 days or more. The device resets itself to retry an upload with loose upload restrictions. This also triggers the use of backup admin params when applicable. |
0x100 | GPS module failed to power on |
0x101 | GPS module failed to power off |
Common Watchdog Reset Reasons - Manually Inititiated Resets
Watchdog Reset Reason | Explanation | Applicable Devices |
0x0 | Either not a watchdog reset, or an unknown error occurred. | All DM devices. |
0x1 |
App reset. This occurs when the device resets itself due to changed conditions. Typical reasons include:
|
All DM devices. |
0x2 | No comms. The device could not communicate with the server for 3 days or more. The device resets itself to retry an upload with loose upload restrictions. This also triggers the use of backup admin params when applicable. | All DM devices. |
0x3 | SMS reset. The device received an SMS command to reset. On some devices, the app reset (0x1) is used instead. | Mainly powered devices. |
0x4 | Async message reset. The device recieved an async message command to reset. On some devices, the app reset (0x1) is used instead. | Mainly powered devices. |
0x7 | Modem brownout. The device has received insufficient voltage and thus the modem is unable to power up properly to connect. | Mainly powered devices. |
Battery Powered Watchdog Reset Reasons
Watchdog Reset Reason | Explanation | Applicable Devices |
0x5 | Backup admin params expired. The device was testing the backup admin params and is now reverting back to the standard admin params. | Battery powered devices. |
Powered Watchdog Reset Reasons
Watchdog Reset Reason | Explanation | Applicable Devices |
0x5 | Under voltage lockout reset. The uvlo was triggered. This is typically seen when the external voltage is too low and the backup battery is depleted. | Powered devices. |
0x6 | Backup admin params expired. The device was testing the backup admin params and is now reverting back to the standard admin params. | Powered Devices. |
Device caused resets - watchdog reasons
Watchdog Reset Reason | Explanation | Applicable Devices |
0x100 | Flash verify failed. | Powered devices. |
0x102 | Bad Header Pointer | |
0x114 | Modem Freeze | Occurs when device is in certain locations with poor coverage. Device will recover when it gets back to coverage. Update to latest FW and modem versions. |