Library use of POWER_ON and RESET_N

[janakelarsson]

After some erratic behavior of the NB and finally a bricked device I looked in the system integration manual and found differences between the use of the POWER_ON and RESET_N pins in the manual and in the library.

(The circuitry on the board makes high output on the microcontroller result in a low level on the modem pins, I'll just describe what happens on the modem below.)

The library pulls down POWER_ON permanently, and uses RESET_N to reset the modem.

The modem expects a low pulse (length 150-3200 ms) on the POWER_ON pin for startup, and another pulse (length at least 1500 ms) for powerdown. It also advises against using the RESET_N pin at all.

I suspect I have bricked one device by using the library restart function too liberally, and that the erratic behavior was caused by an earlier unexpected forced restart using RESET_N at the wrong moment.

I have tried a rewritten variant of the library on a new device, following the SARA-R4 datasheet and systems integration manuals, and it seems to work. I would prefer to remove the use of RESET_N even from the arduino core used, in variant.cpp, I have used that in my tests too.

The systems integration manual recommends monitoring the V_INT pin to detect if the modem is on or not. Unfortunately, this is not connected to the microcontroller on the NB. I am considering options for that.

I can submit a pull request on the rewritten library. Should I?

[hdahle]

I've been struggling with exactly the same, and my conclusions are similar to @janakelarsson

ModemClass::begin(bool restart) contains code that can permanently destroy the SARA-410M module:

  if (_resetPin > -1 && restart) {
    pinMode(_resetPin, OUTPUT);
    digitalWrite(_resetPin, HIGH);
    delay(100);
    digitalWrite(_resetPin, LOW);

This generates a 100ms LOW pulse on the SARA RESET_N pin, which does not reset the device and can actually harm the device:
"An abrupt removal of the VCC supply or forcing a low level on the RESET_N input once the boot of
SARA-R4 series modules has been triggered may lead to an unrecoverable faulty state!" (page 23 in https://www.u-blox.com/sites/default/files/SARA-R4_SysIntegrManual_%28UBX-16029218%29.pdf)

ModemClass::end() also contains code that can permanently destroy the SARA-410M module:

void ModemClass::end()
{
  _uart->end();
  digitalWrite(_resetPin, HIGH);

  // power off module
  digitalWrite(_powerOnPin, LOW);
}

The problem is

digitalWrite(_resetPin, HIGH);

Driving the RESET_N pin HIGH from the processor results in a LOW input to the SARA module. This should never be done except in the case of emergency shutdown. The uBLOX system integration manual says:

"Forcing a low level on the RESET_N input during SARA-R4 series modules normal operations may lead to an unrecoverable faulty state" (page 24 in https://www.u-blox.com/sites/default/files/SARA-R4_SysIntegrManual_%28UBX-16029218%29.pdf)

This part of ModemClass::end() simply does not work at all, but has no fatal consequences:

  // power off module
  digitalWrite(_powerOnPin, LOW);

This is not quite how the SARA R410 should be powered off. As @janakelarsson points out, a power-off sequence is initiated by driving the SARA PWR_ON input low for a duration of 1.5-3.2 seconds. Hence, the _powerOnPin should be driven HIGH for 1.5-3.2s to power the SARA off.

A lot of people probably have bricked their Arduino MKRNB1500 devices simply by using the Modem library. It would be great to update the library!

[janakelarsson]

The library differences can be seen at master...janakelarsson:powerpulse

[hdahle]

@janakelarsson - did you also take a look at variant.h / variant.cpp? I am not sure when initVariant() is called, but the same issues apply:

initVariant() in variant.cpp attempts to power off the module by doing digitalWrite(SARA_PWR_ON, LOW); which does not power off the module at all.

initVariant() also uses digitalWrite(SARA_RESETN, HIGH); in order to put SARA modem in reset on start to conserve power. As we know, using the RESETN signal this way does not reset the device, nor does it conserve power. It merely risks putting the device in an unrecoverable fault state.

void initVariant() {
#if defined(USE_BQ24195L_PMIC)
  pinMode(ADC_BATTERY, OUTPUT);
  digitalWrite(ADC_BATTERY, LOW);
  delay(10);
  pinMode(ADC_BATTERY, INPUT);
  delay(100);

  bool batteryPresent = analogRead(ADC_BATTERY) > 600;
  if (batteryPresent) {
    enable_battery_charging();
  }
  disable_battery_fet(!batteryPresent);
  set_voltage_current_thresholds();
#endif

  // power off the module
  pinMode(SARA_PWR_ON, OUTPUT);
  digitalWrite(SARA_PWR_ON, LOW);

  // put SARA modem in reset on start to conserve power if it's not used
  pinMode(SARA_RESETN, OUTPUT);
  digitalWrite(SARA_RESETN, HIGH);

  // set RTS to LOW
  pinMode(SARA_RTS, OUTPUT);
  digitalWrite(SARA_RTS, LOW);
}

[janakelarsson]

Yes, see arduino/ArduinoCore-samd@master...janakelarsson:powerpulse, the code makes no attempt to power down the module on reboot, to handle that properly we'd need to monitor V_INT, which the hardware does not allow just now.

[aentinger]

Should be fixed by #53 and arduino/ArduinoCore-samd#549 ... maybe you can take a look @janakelarsson ?

[janakelarsson]

No it does not.

The problem is that the power-on and power-off functions in the library does not follow the data sheet. At all. Can I make this clearer? The power-on procedure of the modem is not followed in the library. The power-off procedure of the modem is not followed in the library. It is more luck than anything else that the modem starts at all.

I've rewritten the begin() and end() to follow the data sheet power-on and power-off procedure, including a possibility for AT power-off by a new method shutdown().

The change in #53 only attempts to hide the problem by setting the default begin() argument restart=false. That would avoid the immediate threat of an unwary user bricking the modem by a simple call to begin(), but does not fix the issue. A more savvy user would expect restart=true to restart the modem, whereas there is a real risk that the modem is bricked by issuing begin(true).

The code change in arduino/ArduinoCore-samd#549 is indeed the same as the one I proposed for the variant core, but I would rather that the comment is changed too, see arduino/ArduinoCore-samd@master...janakelarsson:powerpulse Otherwise, the comment will only confuse the reader.

Edited to add: of course, the intended effects of #53 (add file system) and arduino/ArduinoCore-samd#549 (add second stage bootloader) are certainly good (but they do not have the side effect to fix this problem).

[aentinger]

@giulcioffi 👋 ☕ Can you please take another look at this?

[janakelarsson]

See page 23 onwards in https://www.u-blox.com/sites/default/files/SARA-R4_SysIntegrManual_%28UBX-16029218%29.pdf

[zbelding]

This issue was raised December 2019: https://forum.arduino.cc/index.php?topic=654725.0

Also see from ublox SARA R4 data sheet:

[zbelding]

It is more luck than anything else that the modem starts at all.

I agree.

[ircole]

I'm fairly new to the Arduino world so forgive me asking if this isn't proper. I have this problem (and more) with the MKRNB1500. When do these issues that have been identified picked up in an update to the library? From my observations it doesn't appear that Arduino is paying much attention to the MKR1500 which is disappointing as my plan was to use it for monitoring crude and salt water levels in storage tanks as well as monitor several other sensors. My experience is that it is not reliable enough to depend upon for 24/7 365. I was excited when I found the MKR1500 but have spent many hours trying to get it to not hang up. The power off and on is one of the areas. How timeouts are handled is another. My intent isn't to throw stones, rather understand how support for Arduino devices works. Maybe the intent isn't to have something that can be depended upon rather just for experimenting with.

[janakelarsson]

I believe this was in the library from the start. From what I understand, the MKR NB 1500 library was started from the MKR GSM 1400 library which uses the UBLOX SARA-U201 modem. The NB 1500 uses a UBLOX SARA-R410M modem, which has a different power-on procedure from the SARA-U201.

I have not used the MKR GSM 1400 so I cannot say how well the MKRGSM library works. Perhaps there are no problems.

However, it seems to me that the power-on sequence of the MKRNB library follows the system integration manual of the SARA-U201 instead of the system integration manual of the SARA-R410M. Of course, since the MKR NB 1500 uses a SARA-R410M, this is bad. The MKRNB library should follow the system integration manual of the SARA-R410M modem.

The changes I propose makes the MKRNB library follow the system integration manual of the SARA-R410M modem, as far as the hardware allows. I would have liked to be able to monitor the V_INT pin of the modem, as the system integration manual recommends, but that is not possible with the current hardware.