New firmware release 1.7.6.b1

[this.wiederkehr]

@daniel could you please update the github repo. Thanks.

[BetterAuto]

Just want to say thanks to the Pycom team for working hard on this software. Glad the bug fixes are coming rapidly.

[urbanzz]

@daniel .esp32: Fix bug related to setting the UART parity in the constructor
Bingo! It was my headache during Modbus protocol implementation....without logical analyzer i was stucked with my device when configured exchange with EVEN parity..afterwards simply changed to NONE

[Eric24]

@jmarcelino Understood. We're looking at FRAM too, as well as NVRAM in an external RTC (that can be powered directly from the battery, independently of the pycom module).

I definitely agree that it should be possible to "redirect" the storage location. Maybe it's as simple as a couple of functions (i.e. read and write) that could be passed in on LoRaWAN init. If they are not included, the existing flash-based storage works by default, otherwise these functions handle the "abstraction layer" for any sort of NV storage.

[jmarcelino]

@Eric24
It's complicated in LoRaWAN because if you lose your frame counters due to loss of power when using ABP activation the network will reject your packets until the frame counter returns to the previous value. Also I think the upcoming deep sleep shield resolves the power consumption issue by fully powering off the ESP32. So the non-volatile aspect is important.

In applications where I can't use LoRaWAN as a "dumb pipe" (disabling frame counter checks, fixing ABP keys) I've used SPI/I2C connected Ferroelectric RAM (F-RAM) which is non-volatile and supports 100 trillion read/write cycles.

The good news is it should be possible to "redirect" NVS writes to an external lasting memory like this. But it will take some digging into the source code and I think users need be aware of this Flash lifetime limitation so it shouldn't be done automatically.

[Eric24]

@jmarcelino Yes, this is why I'd rather see the RTC's NV-RAM used for this. The advantage to using flash is that the LoRaWAN state would survive a complete power outage, although I'm not sure that outweighs the issue of flash wear that you bring up. Most LoRaWAN applications I can think of would indeed spend a lot of time in deep-sleep but still with power available (and the NV-RAM is powered in this state), rather than needing to "pick up where it left off" after having zero power. Can you think of any applications where maintaining state through a complete power outage is advantageous?

[jmarcelino]

@daniel said in New firmware release 1.7.6.b1:

esp32: Store the LoRaWAN state in NVS

Very curious to know/see the source about this, does it use the new wear levelling component or just plain NVS writes (translated to spi_flash_write)?

It's just that the flash memory chip is only rated at 100,000 program/erase cycles, i.e. way less than packets sent by many LoRa applications.