Wrong Reset Procedure in MODEM.cpp

[mc-n]

We have experienced rare crashes of the U Blox Modem after longer periods in 2G fallback mode. The 2G fallback is neccessary due to 3 G network shutdowns here in germany. The first problem was a much longer network logon time which could be solved by prolonging the timeout values.

The next problem here is that even with a complete MCU reset cased by watchdog timers at some point the modem cannot be reset to a working condition. This is a big problem because in our use case the modem is installed in a very remote location.

I looked at the reset-procedure of the modem and found the following code lines in MODEM.cpp / int ModemClass::begin(bool restart)

pinMode(_resetPin, OUTPUT);
digitalWrite(_resetPin, HIGH);
delayMicroseconds(150);
digitalWrite(_resetPin, LOW);
delay(3);
digitalWrite(_resetPin, HIGH);
delay(600);
digitalWrite(_resetPin, LOW);

However if I have a look at the u-Blox SARA U201 Datasheet (https://www.u-blox.com/sites/default/files/SARA-U2_DataSheet_UBX-13005287.pdf) which is the Modem used on the MKR GSM 1400 Board, i find the following info (Page 30):

The RESET_N input line has to be driven as described in Figure 5 to perform an abrupt “external” or “hardware” reset (reboot) of the SARA-U201 modules: • RESET_N line has to be set to the LOW level for 50 ms (minimum)

The reset procedure in the MODEM.cpp code does however match to the datasheet for the SARA-U260, SARA-U270 and SARA-U280 modules:

The RESET_N input line has to be driven as described in Figure 6 to perform an abrupt “external” or “hardware” reset (reboot) of the SARA-U260, SARA-U270 and SARA-U280 modules: • First, RESET_N line has to be set to the LOW level for 100 μs (minimum) to 200 μs (maximum) • Then, RESET_N line has to be released to the HIGH level for 2 ms (minimum) to 4 ms (maximum) • Then, RESET_N line has to be set to the LOW level for 500 ms (minimum)

I guess there was made a mistake by adapting the reset procedure for the other SARA modems. Could you please give me feedback if that's correct? If so I would recommend using thins procedure:

pinMode(_resetPin, OUTPUT);
digitalWrite(_resetPin, HIGH);
delay(10);
digitalWrite(_resetPin, LOW);
delay(60);
digitalWrite(_resetPin, HIGH);

However I cannot tell at the moment If that will solve the modem hangs but I will try the right procedure and give feedback.