If the source code for B-L072Z-LRWAN1 does not implement state preservation, then we need another alternative provision or direct efforts into implementing state preservation.
What would be the best way to put our effort into this?
Take time to understand how little is different between the Nucleo and the Murata module (same processor core, potentially different SPI and GPIO pins used to talk to the radio).
Extract the functionality from the AT example and move it to the stand alone one. Or keep the AT example, which fit your original intent to use dual processors.
Personally I’d look at the 1SJ module instead as that also gets you the newer lower power radio, but those are less consistently available and less documented, so the project while ultimately better is going to be harder still, probably for where you are right now you need to pick a path of least resistance.
You’ve decided to do something unusually difficult (energy harvesting) but that also means that every other part of your system is going to be as difficult as normal, if not more so.
That sounds a better plan!
We shall take up Nucleo example to trace the functional calls and replicate into the stand alone example.
Thanks Much!!
I would not recommend using the STM32CubeExpansion pack at all. Best to use the Semtech version direct from Github. While the ST version is easier to use, it uses a very old version of the Semtech LoRaMAC-node stack, which likely does not have the latest features. The EEPROM state preservation feature was added to the Stemtech code in the v4.4.7 release and its likely its not been packaged into the ST version.
The original Semtech version has an implementation for the B-L072Z-LRWAN1. I compile and develop on Visual Studio code on Ubuntu 20.04. Its virtually impossible to get it working on Windows. Too much complication. The readme on the repo has info on compiling and uploading code to the dev board.
1 Like
Nope, me neither, I’d recommend Microchip Studio / SAMR34. It lets me do everything for a simple device in two pages of A4 all in the same file if I so choose.
Both code bases are prime examples of “easy to use if you happen to have written the code base” so it’s all a bit relative. But after a few weeks of playing hunt the file to edit, you start getting numb and stop caring.
v2.1 has LoRaMAC-node v4.4.7, so I suspect it’s as up to date as it’s going to get before the switch to LoRaWAN v1.1, coming soon. Only laggards would only just be moving to v1.0.3. Oh. Wait. That’s us.
The NVM routines should really be provided as stubs - next thing we’ll know is that the LoRaMAC code base will have peripheral & sensor code and a mini-scheduler principally to drive the Blinkenlights. Oh. Wait. Never mind, it already has.
Clearly IBM felt the need to compete with their own mini-RTOS/scheduler in LMIC as well. But then separation of concerns and simplicity aren’t really in vogue. More mahoosive Swiss Army knife - the one with the hoof pick & USB drive - big & clunky and very inefficient to use as a tool.
The Semtech reference boards cover a range of vendors and the BSP files are separated out from the LoRaWAN code which is probably why the EEPROM functionality wasn’t picked up by ST as I’m sure they’d prefer us to use the 330Mb CubeMX zip file with no examples for any MCU older than two years.
Not that I’m getting bitter & twisted. Oh. Wait. That already happened. 
1 Like
Hi @MedadNewman, @descartes
We found that state preservation is available for NucleoL073 board.
We see two different approaches here -
- Modify B-L072Z-LRWAN1 source files to match NucleoL073 state persistence feature.
- Modify NucleoL073 source files to match B-L072Z-LRWAN1 board settings.
We see that option-2 is path of least resistance.
Do you concur on this?
Thanks
No, option 2 is a huge fundamental set of changes to an already complex code base.
Option 1 could be as simple as copying a 2 or 3 files over.
Thanks, @descartes
We would be looking at copying only “NVM” routine files into B-L072Z-LRWAN1 source files.
It’s not trivial but both situations have the same processor connected to the same radio, only via different pins, so there are only a limited number of places that’s going to show up - SPI bus number, pin assignments, and maybe the choice of debug UART.
Correct.
We shall explore the pin and peripheral assignments.
We have checked the source code for B-L072Z-LRWAN1 and it does have NVM usage for state preservation.
(
- // Restore data if required*
- nbNvmData = NvmDataMgmtRestore( );*
)
It needs modifications to handle power-on reset and resume scenario.
Might I suggest a 3rd approach, perhaps an even lower resistance path 
:
- Acquire a NucleoL073 dev board and test on that
Regards
Medad
1 Like
We shall try out implementation using B-L072Z-LRWAN1 source files.
It has the same initialization sequence for LoRa as NucleoL073.
We suppose both are equal upon compilation for respective targets in LoRa parameter management using state persistence.
Thanks @MedadNewman @descartes @cslorabox