LoRaWan - node.saveSession possible problem - EEPROM details ?

[michapr]

Hi,

could it be possible to publish here some more details about the save procedure ?
node.saveSession();

Where the values will be saved (address) - so that it will not be overwritten by user code?

I have the unclear effect in this time, that "sometimes" the value from
node.getFcntUp() after successful node.restore() will be changed to lower value, when I update the sketch.

As sample was all the time increasing up to 499 (even after restart, reboot, changing something in sketch etc.) - then have only replaced the delay(delayMs); in LoRaWAN_End_Device_Reference.ino with

esp_sleep_enable_timer_wakeup(1000*(uint64_t)delayMs);
esp_deep_sleep_start();

and the new counter value was 384 ...
(in result the values will not be received more by TTN of course...)
What now happen is interesting for me... in the loop the counter will go up to 433 and then fall back to 384 again
(using an esp_deep_sleep_start(); at the end of the loop, adding a delay(50) before...)

The save procedure is "working" - checked in log:

  state = node.saveSession();
      if(state == RADIOLIB_ERR_NONE) {
      Serial.println(F("save success!"));
    } else {
      Serial.print(F("save failed, code "));
      Serial.println(state);
    }

BTW: for testing issues would be great to have a function like node.setFcntUp(value) - for skipping the loop count to last value?

I had same issues yesterday, but have no idea when and why it happen... will try to reproduce of course.

Any idea?

THANKS!

[StevenCellist]

No need to reproduce, it's in an open (and solved) issue. Wasn't bothered yet to integrate it with a PR yet, it will come very soon (aka this weekend) combined with more improvements. See #950 for the solution.

[michapr]

Thank you for information, didn't found it...