Making OTAA work with STM32 I-CUBE-LRWAN library

End Devices (Nodes)
1

Just for future reference, here is how to configure the STM32 I-CUBE-LRWAN library for OTAA.

I now understand my basic mistake in configuring it, as discussed in OTAA Join Debugging.

Although there are some hints in the library code, mentioning LoraWAN 1.1.x specification, the project comes pre-configured using LoraWAN 1.0.x spec.
I just read carefully through the comments in Commissioning.h and now understand, the Constant LORAWAN_NWK_KEY has to be set to equal LORAWAN_APP_KEY. Then, the keyID = NWK_KEY can be left as it originally is. There is a #define switch in LoRaMacCrypto.c to change to LoraWAN 1.1.x spec, but this causes my compiler to fail with a warning the program would not fit into memory any more.
So when staying with the default value of

#define USE_LRWAN_1_1_x_CRYPTO   0

in LoRaMacCrypto.c, make sure you set

#define LORAWAN_NWK_KEY    LORAWAN_APP_KEY

in Commissioning.h

Then not only the Join Request will be signed with a valid MIC, but also the Join Accept Response by the Network will be understood by the End Node.

I couldn’t really find that pointed out clearly in ST’s documentation, also most online-tutorials won’t use OTAA but ABP and therefore use totally different settings in this file.

Hope this helps whoever might run into the same problem.

5 Likes
2

@krobidiotics can you give me details about your node setup? Which boards and I-CUBE-LRWAN library version did you use?

3

Hi @AndrFerreira - So far I had just started to play around with a NUCLEO L053R8 board and the SX1272MB2xAS mbed shield.
I used the I-CUBE-LRWAN Expansion in Version 1.3.1

Since there are some other projects that became urgent, the LoRaWAN node project currently ‘sleeps’ somewhere in the back of my desk… I hope to get back to it somewhere in the next 2 weeks or so.
Also, it’s quite some time ago I built my last STM32 projects and I still need to get into how to use the new STM32CubeIDE (used to work with the SW4STM32 before and thought it might be worth a try…)

4

Hi @krobidiotics, thank you very much for the feedback.

I am new to both Lora and STM32 :slight_smile: I am using the I-NUCLEO-LRWAN1 shield and the NUCLEO-L073RZ board. I am having issues with the node architecture because by reading the documentation it seems that the I-NUCLEO-LRWAN1 shield is a fully autonomous end node and just uses the NUCLEO-L073RZ board for power supply. However, when I select the projects on the I-CUBE-LRWAN Expansion the target is the NUCLEO-L073RZ board. So my question is: the end node application on the I-CUBE-LRWAN Expansion is for which platform, the NUCLEO-L073RZ board, or the I-NUCLEO-LRWAN1 shield?

5

additionally, how is the communication flow between the two boards?

6

This is a situation which has a lot of complexity as a result of having a lot of options. It may be that it makes it less than a great starting point for a first effort.

The I-NUCLEO-LRWAN1 features the USI LoraWAN module WM-SG-SM-42 with preloaded AT-Command software, and can be controlled from an external host such as NUCLEO-L053 boards. You can also develop your own application based on the I-CUBE-LRWAN to control it without external host. You just need to correct the ping definition and antenna switch logic to run the I-CUBE-LRWAN on the I-NUCLEO-LRWAN1.

Let’s break that down:

  1. The “shield” contains a module, and the module contains both an SX127x radio and an STM32L0 processor, probably comparable to the STM32L051 given the listed RAM and FLASH (8/64K) which would make it the resource constrained little brother of the STM32L073 on your Nucleo host board, but I don’t know the exact STM32 they are using.

  2. It supposedly ships with an AT command set firmware in the module, you could interact with that from a host processor, ie on the conventional Nucleo you stack it on (or maybe even an Arduino). Traditionally the communication in that sort of setting would be a logic level asynchronous serial port (ie, you use the host UART) but other possibilities like I2C or SPI sometimes show up in these schemes. I didn’t find specifics for this hardware so thinking it primarily uses a UART is speculation, but of a fairly sound sort.

  3. If you don’t like the factory build of the AT command firmware, you can build a new one, maybe from that github repo or somewhere else, and then flash it to the STM32L0 in the module on the shield.

  4. If you don’t want a stack of two boards, then you can dispense with the “host” board, power the shield somehow, and build a firmware where all the code runs on a single processor which directly controls the radio via SPI and GPIOs, and flash that on the STM32L0 in the module on the “shield”. The github repo’s readme shows the peripheral assignment changes needed to run one ST project on the shield’s processor instead of on a conventional setup like an SPI radio-only shield stacked on a STM32L0 Nucleo.

8

2 posts were merged into an existing topic: I Cube LRWAN problem