Open stoberblog opened 3 years ago
@andysan was looking into the context saving feature using settings API. @andysan can you please share the status?
I have an implementation of it on this branch: https://github.com/andysan/zephyr/commits/lorawan-api-draft
The commit of interest is this one: https://github.com/andysan/zephyr/commit/10db887238c0145a9567dff2f19074013bb1b8ef
The context handling in upstream LoRaMAC is, as far as I can remember, a beta feature. In fact, there was a major refactor a few weeks ago to solve some issues with the current implementation. Some of it was a result of this ticket: https://github.com/Lora-net/LoRaMac-node/issues/882
That said, my context save and restore was working on my api-test branch was working last time I tested. I think I tested it on both an NRF52-base board with a SX126x and the STM32-based Murata board.
The branch above is pretty old and needs to be rebased. It has some other usefull features, like Class C support and support for listening for packets, so I should probably sit down and do it. :)
So I also have a project working on the nRF52840 however, I had to implement: ram retention (nordic specific), determining wake up reason (nordic specific - I wanted to join on a real restart and continue session upon wake up) and create extra LoRaMac wrapper code so I could access the internal LoRaMac context (as per https://github.com/Lora-net/LoRaMac-node/issues/678), which I then used to write/read to/from RAM.
I also have had a try at having the code gracefully fail upon no LoRa SX1276 hardware attached as I was doing this in testing
Hi @andysan,
This issue, marked as an Enhancement, was opened a while ago and did not get any traction. Please confirm the issue is correctly assigned and re-assign it otherwise.
Please take a moment to review if the issue is still relevant to the project. If it is, please provide feedback and direction on how to move forward. If it is not, has already been addressed, is a duplicate, or is no longer relevant, please close it with a short comment explaining the reason.
@stoberblog you are also encouraged to help moving this issue forward by providing additional information and confirming this request/issue is still relevant to you.
Thanks!
Is your feature request related to a problem? Please describe. I want to deep sleep on an nRF52840 and also turn off power to my LoRa module. After waking up from deep sleep, I'd then re-power the LoRa module, restore the LoRaWAN to the pre-reset state (so I don't need to keep rejoining) and then continue to transmit data. There are others requiring/using this feature as seen here https://github.com/Lora-net/LoRaMac-node/issues/678
Describe the solution you'd like The backend module used by Zephyr already has example application to do this (look at loramac-node/src/apps/LoRaMac/common/NvmCtxMgmt[.c/.h]), its however needs to be made more generic. I for instance want to use these in conjunction with the flash drivers ( flash_write() and flash_read() ).
Describe alternatives you've considered Alternatively, and what I was actually trying, is insight into how I #include. This would allow the ability to reach the factions required to get the internal structures that can be mem copied elsewhere. This method seems to be frowned upon judging from https://github.com/zephyrproject-rtos/zephyr/issues/25956