Sunday 4 February 2018

Getting started with the STM32 LoRa Discovery Kit


After having done a number of embedded projects using the Microchip processors and development stack, I figured it was about time to try something else for a change. Fortunately I was able to attend the first TheThingsNetwork developer conference in the Netherlands, where I was given an ST Microelectronics B-L072Z-LRWAN1 Discovery board. This board contains everything you need to get started in the world of LoraWAN. The STMicro site lists the following specs:

Key Features
  • CMWX1ZZABZ-091 LoRa® module (Murata)
    • Embedded ultra-low-power STM32L072CZ Series MCUs, based on ARM® Cortex® -M0+ core, with 192 Kbytes of Flash memory, 20 Kbytes of RAM, 20 Kbytes of EEPROM
    • USB 2.0 FS
    • 4-channel,12-bit ADC, 2xDAC
    • 6-bit timers, LP-UART, I2 C and SPI
    • Embedded SX1276 transceiver
    • LoRa® , FSK, GFSK, MSK, GMSK and OOK modulations
    • +14 dBm or +20 dBm selectable output power
    • 157 dB maximum link budget
    • Programmable bit rate up to 300 Kbit/s
    • High sensitivity: down to -137 dBm
    • Bullet-proof front end: IIP3 = -12.5 dBm
    • 89 dB blocking immunity
    • Low RX current of 10 mA, 200 nA register retention
    • Fully integrated synthesizer with a resolution of 61 Hz
    • Built-in bit synchronizer for clock recovery
    • Sync word recognition
    • Preamble detection
    • 127 dB+ dynamic range RSSI
  • SMA and U.FL RF interface connectors
  • Including 50 Ohm SMA RF antenna
  • On-board ST-LINK/V2-1 supporting USB re-enumeration capability
  • USB ST-LINK functions:
  • Board power supply:
    • Through USB bus or external VIN /3.3 V supply voltage or batteries
  • 3xAAA-type-battery holder for standalone operation
  • 7 LEDs:
    • 4 general-purpose LEDs
    • A 5 V-power LED
    • An ST-LINK-communication LED
    • A fault-power LED
  • 2 push-buttons (user and reset)
  • Arduino Uno V3 connectors
  • ARM® mbed (see http://mbed.org
 Nice! Sounds like the perfect opportunity to start in the world of STMicro ARM processors (More info can be found on the STMicro website).

So now: how to get it to work? Although there were several workshops on this subject during the conference, there weren't many people that actually got the board to work and connect. The instructors did their best, but the STMicro development stack just isn't as straightforward to install and set up as Arduino's. Each workshop left us struggling with a multitude of drivers to install, accounts to set up and a confusing number of choices on Development tools. A quick Google search revealed that we were not alone in this; countless discussions on forums are describing the same experience. Once home, I decided to take some time to find out what actually needs to be done to get the board to work and do a small tutorial, so here it is!

Prerequisites

 

For this writeup I am going to assume that you already have a TheThingsNetwork account, and are familiar with LoraWAN. If not, please go to the TheThingsNetwork website and create an account (it's free), and read up on LoraWAN and TTN (This link is a good start).
Before downloading from the links below, you will also need to create an STMicro account (Click here). You will need it to access the downloads on their website.

What to get?

 

STLink driver
The Discovery board comes with a built-in ST-LINK programmer / debugger, for which you will need a driver. This can be downloaded here. Please install this FIRST, before plugging in the Discovery board.

I-CUBE-LRWAN (LoRaWAN software expansion for STM32Cube)
This package contains all libraries and demo projects. It can be downloaded here.

KEIL MDK
In this tutorial I've decided to use the Keil MDK IDE. You can download it here. Please take the time to create an account and register your version of MDK (it's free for STM32F0 and STM32L0 series processors). You will need to have a license in place to be able to successfully build the demo application.

Putting it all together

 

Set up communications
Once the driver is installed, you should be able to start communicating with the Discovery board. The board comes pre-loaded with firmware which will send the DevEUI, AppEUI andAppKey over a serial connection. So, let's make this happen!
First, Connect the board and then open your Device Manager. Your board should be listed in the ports list:

On my system the board COM port is COM5. Open a serial monitor program (I used the serial monitor in the Arduino IDE) and select COM5. Now press the Reset button on the board and something like this will appear:

Register your device
Now go to console.thethingsnetwork.org and register your device on the TTN. Never done this before? Not to worry; TheThingsNetwork has an excellent tutorial right here.
The DEVEui will need to be entered during registration; the AppEui and AppKey will be generated during device registration. These we will need to enter in our project.

Enter the keys in your Project
Now it's time to open the demo Project in Keil MDK. Start the program and open the demo project (Project -> Open Project...) located in the I-CUBE package you have downloaded. There is a separate demo project for each Discovery board and tools stack, which leads to a quite complicated directory structure. This is what it should look like:

ICUBEDIR\Projects\Multi\Applications\LoRa\End_Node\MDK-ARM\B-L072Z-LRWAN1

Load the project file and build it to make sure that all components are OK.
Now it's time to enter the keys. This needs to be done in the file commissioning.h, which is located in the directory Lora\End_Node_inc:


Open the file in MDK and enter the AppEui and AppKey. Do not alter the DevEui; this is not used in OTAA activation. Save the file.

Build the Project and update the Discovery board
Now Rebuild the Project. If the build is successful, you will be able to load the generated firmware into the Discovery board. Use menu Flash -> Download to update the firmware in your device and then press the Reset button on the board.

Done!
The serial monitor should now list something like this:

That's it! Your device is now joined and will start sending data to the TTN network. You can of course monitor this in the TTN console.


Next steps?

 

Getting the device to work is only the first step of course. You will now need to take it further by adding sensors and modifying the code to make it do what you have in mind. Good luck, and please leave feedback below if you found this tutorial useful!

14 comments:

  1. Hey, What I'm getting on TeraTerm is this-
    APP_VERSION= 01.03.00.00
    MAC_VERSION= 04.04.02.00
    OTAA
    DevEui= 34-35-31-31-61-37-8F-11
    AppEui= 70-B3-D5-7E-D0-02-60-FA
    AppKey= 4D 93 57 A4 78 68 48 35 65 C8 29 7B F7 60 0D AC
    1s603: PHY txDone
    6s836: PHY rxTimeOut
    7s837: PHY rxTimeOut
    How do i check about the receiving end?

    ReplyDelete
    Replies
    1. This is a bit of a late reply but it may help others: Please make sure that you are in range of a TTN gateway before running this experiment. To check this, you can use the ttnmapper site listed in my page links.

      Delete
  2. Thanks a lot for sharing very informative docs.

    ReplyDelete
  3. Hello,
    I have DevEUI, AppEUI and AppKey. In the commissioning.h file I replaced the JoinEUI with AppEUI and NwkKey with AppKey thats the only Things i changed. But it is not working. I Always get a PHY rxTimeOut. Do you know where the problem could be?
    Thanks

    ReplyDelete
    Replies
    1. Hi! Sorry it took me a while to respond. Are you sure you are in range of a TTN gateway?

      Delete
    2. Hi, thanks for doc!

      Do you have an idea, where to configure the regional parameter setting?

      I have a gateway nearby configured to IN-ISM on SenRa network server.

      I have defined #define REGION_IN865 in the main.c & still get the PHY rxTimeOut.

      Delete
    3. Hi,

      Do you see the join request arriving at the gateway? If so, the region has probably been set correctly. If the request times out, try to set up the device as ABP first as it is less critical to set up and doesn't rely on return messages.

      Delete
  4. Hi, thanks for the nice tutorial! I have changed the Appkey and AppEUI in commissioning.h and that is the only change that I've made but I have this error "".\sx1276mb1mas\NUCLEO_CUBE_LORA.axf" - 1 Error(s), 0 Warning(s)."
    do you know how can I solve this?

    ReplyDelete
    Replies
    1. Hi, if the project compiled OK before you made the change it has to be an error in the way you entered the new values (but you knew that, right)? Just undo the changes and redo one by one. Type the codes in by hand if you have to, sometimes copy & paste includes spaces or other characters that will cause errors.

      Delete
  5. Hi,
    thanks for the nice tutorial.
    I followed everything step by step and I changed the Appkey and AppEUI in commissioning.h but I have this error "".\sx1276mb1mas\NUCLEO_CUBE_LORA.axf" - 1 Error(s), 0 Warning(s)". could you please help me?

    ReplyDelete
  6. Hello,
    Very nice tutorial. I see that I have a lot of informations with the current Tx.
    Do you know how to send juste 1 bit and nothing else. What I can modify ?
    Sorry if my English is bad.
    Thanks

    ReplyDelete
    Replies
    1. Hi,
      The amount of information you send is set in main.c, lines 281 - 291. You can of course replace that block and add only one bit in the send buffer. If that's all you need you can also remove lines 263 - 268 and 272 - 278.
      The device will still send header information of course, to identify itself. The minimum amount of data it will always send is 13 - 14 bits IIRC.
      Good luck!

      Delete
  7. Hi, I want to configure my dev board to send to ttn, I already have connection to TTN, but the node just send 7 messages and no more, I configure the RegionUS915.c and RegionUS915.h to force send only by 8 channels. I saw if I use the 64 channels the node works perfectly, but with 8 it doesn't work. Can you help me?, please. Thanks in advance

    ReplyDelete
    Replies
    1. Hi, there is no reason why the dev board should limit the messages to just 7. However, it WILL enforce the TTN dutycycle IIRC. This means that it will stop sending if you send too many messages too quickly. Please try to limit sending your messages to 1 every 10 minutes or so and see if that works? The TTN site has docs on dutycycle.

      Delete