Adding the I-CUBE-LRWAN library to a STM32CubeMX project

[Alexandre Jamet]

Posted on January 02, 2018 at 14:09

My team and I are currently working on a project that involve a ST board (the STM32L072CZYxx) to create a bidirectionnal GSM-LoRa gateway.

As we've already succeeded in implementing the GSM side of the gateway, we are currently working on the LoRa part of the project. To achieve this, we're trying to use the

http://www.st.com/en/embedded-software/i-cube-lrwan.html

, but can't figure out how to add this library to the

http://www.st.com/en/development-tools/stm32cubemx.html

project. It seems like, this library can't be added to our project through STM32CubeMX. The only solution we have is to add manually the library to the project but we can't figure out how to do it. We imported the middlewares we needed into the project however, the IDE we use (Atollic TRUEStudio or SW4STM32) detects a lot of errors in the project and we really don't understand why (the source for middlewares were coded by ST, so basically no errors).

#lorawan #b-l072z-lrwan1 #lora

[Tesla DeLorean]

Posted on January 02, 2018 at 17:44

The Cube 'Add-On' libraries don't integrate with CubeMX despite what you think the name would suggest. This has been discussed before, a bit like Microsoft stuffing .NET on to everything and it not meaning the same thing.

The LRWAN code uses HAL, if you must use CubeMX to generate your HAL code then you'll need to push it to a separate project, and then merge in the functionality you want. I would suggest you learn the HAL paradigm and then code your solution directly.

The LRWAN code is also somewhat tortuous, and has several spin-loops and interrupt issues that will cause data loss on multiple interfaces if not addressed.

[Andrew Neil]

Posted on January 02, 2018 at 18:29

Clive One wrote:

The LRWAN code is also somewhat tortuous

No kidding!

:(

[Tesla DeLorean]

Posted on January 02, 2018 at 18:43

I'm not sure where Semtech's and ST's code begins and ends, but it ends up a bit of a Frankenstein's monster fitting the pieces together and using the RTC as a time base to keep the power low. There are more concise SX1276 code implementations, so it is helpful to get familiar with the chip itself and how it fits into the abstraction/implementation.

The LRWAN and CubeMX forms don't mesh at all well.

[adibacco9]

Posted on June 09, 2018 at 20:00

I cannot believe that the End_Node project, for example, cannot be copied in another place and easily modified to include LRWAN files.

[Tesla DeLorean]

Posted on June 09, 2018 at 21:32

>>I cannot believe that the End_Node project, for example, cannot be copied in another place and easily modified to include LRWAN files.

I'm not even sure that was the original issue. These project can be cloned, quite easily in Keil. In fact in Keil I almost never create a project from scratch, because it's several orders of magnitude simpler to duplicate/clone an existing one with 99.999% of the functionality and settings desired as a starting point, and cull the pieces I don't want.

I've seen Eclipse based tools make a complete dogs-breakfast out of whatever their 'Workspace/Project' structure is with respect to files in fixed locations, or with non-relative formats. They might have improved things since I last tried, but Atollic for example was so brain damaged that it was an experiment I refused to repeat. ie Learn from failure so as not to fail again.

The prime issue of the OP though seemed to be the ability to slap CubeMX and LRWAN code together. Which in my opinion is like mixing Oranges and Onions together because they both start with 'O', then complaining that the resultant smoothy tastes horrible.

The LRWAN code is a result of HAL code being merged into a Semtech model, while CubeMX generates HAL code for some entirely different model/mindset.

You can try to combine them in whatever way you think works for you, but the path of least resistance is to move code into the Semtech model, rather than implement LoRa in CubeMX, and this also makes life easier later when a new release of LRWAN inevitably comes along. I say this as someone who took the LRWAN v1.1.2 code and ported it to half a dozen different STM32 families and boards ST didn't provide direct/immediate support for.