L072Z-LRWAN1 Discovery kit + LMIC + Arduino

End Devices (Nodes) LMIC
1

ST B-L072Z-LRWAN1 board with Arduino framework and LMIC.
Does anyone have this combination working?

I’m trying to get this to work but run into some issues:

Description

I use Platformio and have defined disco_l072cz_lrwan1 as board with Arduino as framework.
If I’m correct this will use the STM32 Arduino Core.
LoaRaWAN library used: MCCI LoRaWAN LMIC library.

The sketch is tested proven code that runs without issues on other boards.

My platformio.ini looks like this:

[env:disco_l072cz_lrwan1]
platform = ststm32
board = disco_l072cz_lrwan1
framework = arduino
upload_protocol = stlink
monitor_speed = 115200
lib_deps =
    MCCI LoRaWAN LMIC library

The SX1276 on the Murata module is not connected to the standard SPI port.
Standard SPI is configured using the values MOSI, MISO and SS which are defined as:

MOSI  PB15  (11)
MISO  PB14  (12)
SCK   PB13  (13)

While the SX1276 uses the following:

RADIO_MOSI_PORT    PA7   (34)
RADIO_MISO_PORT    PA6   (35)
RADIO_SCLK_PORT    PB3   (36)

RADIO_NSS_PORT     PA15  (37)
RADIO_RESET_PORT   PC0   (33)
RADIO_DIO_0_PORT   PB4   (38)
RADIO_DIO_1_PORT   PB1   (39)
RADIO_DIO_2_PORT   PB0   (40)

LMIC can only use the default SPI. I therefore redefine the SPI pins in setup() before calling any LMIC code. Like this:

setup
{
    SPI.setMOSI(RADIO_MOSI_PORT);
    SPI.setMISO(RADIO_MISO_PORT);
    SPI.setSCLK(RADIO_SCLK_PORT);
    SPI.setSSEL(RADIO_NSS_PORT);
    SPI.begin();
    ...
    os_init();
    LMIC_reset();
    ...
}

The pin map is:

const lmic_pinmap lmic_pins = {
  .nss = RADIO_NSS_PORT,
  .rxtx = LMIC_UNUSED_PIN,
  .rst = RADIO_RESET_PORT,
  .dio = { RADIO_DIO_0_PORT, RADIO_DIO_1_PORT, RADIO_DIO_2_PORT }
};

Issue 1

The code compiles successfully but uploading fails with the following error message:

Configuring upload protocol...
AVAILABLE: blackmagic, jlink, mbed, stlink
CURRENT: upload_protocol = stlink
Uploading .pio\build\discovery-l072z-lrwan1\firmware.elf
xPack OpenOCD, 32-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-07:34)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
debug_level: 1

srst_only separate srst_nogate srst_open_drain connect_deassert_srst

Error: init mode failed (unable to connect to the target)
in procedure 'program'
** OpenOCD init failed **
shutdown command invoked

*** [upload] Error 1

The ST-Link drivers v2.0.1 are installed (running on Windows 10).
In Device Manager the board is visible as STMicroelectronics STLink Virtual COM Port (COM17)
In Device Manger the board is recognized as ST-Link Debug.
In the system tray the board is visible as STM32 STLink (with drive DIS_L072Z).

It looks like everything is installed and configured correctly but the upload fails.

Issue 2

As workaround for issue 1 I have upgraded the on-board ST-Link programmer to J-Link OB.
After the upgrade the board is recognized as COM port ‘JLINK CDC UART Port’
For JLink the upload_protocol in platformio.ini must be set to jlink.
After these changes I was able to upload the sketch to the board and even got output in the serial monitor via the (JLink) USB port.

When trying to run the sketch, it hangs after a packet is queued. In the middle of printing text to the serial port (probably while handling the EV_TXSTART event):

000000000267:  Event: EV_JOINING
000000000410:  Packet queued
00

The join request is never transmitted (not visible in TTN Console).

Questions

What could be causing these issues?
Any ideas how to fix them?

Update:
A workaround for Issue 1 is to use upload_protocol = mbed instead of stlink (which is default).
But that also requires upload_port to be specified, in my case upload_port = F:
The mbed upload protocol uses Mass Storage for firmware upload (which is actually a file copy) and therefore the board’s drive letter has to be set as upload_port (the value of upload_port is platform specific).

2

Given MCCI’s own STM32 board also uses the Murata module, if you use their Arduino core rather than someone else’s you shouldn’t have to make much in the way of changes, except possibly for the TCXO power control pin.

As for the serial issue, maybe try using an outboard USB-serial to get away from any Segger weirdness.

3

The programmer is integrated on board so that an external programmer is not needed and also provides Serial over USB and integrated debugging facilities so I prefer to use the onboard programmer instead.

First, this is not about just ‘someone else’s’ Arduino core but about the ST Microelectronics supported Arduino Core STM32 which includes support for this board (but does not integrate LoRaWAN support).
Second, this is not an MCCI-Catena board so it is not logical to use their Arduino core that is specificly designed for their boards.

And most important, this is to be part of a multi-platform example LoRaWAN application, so it should be straightforward and work right out of the box (with PlatformIO).

4

Well… the folks over at MCCI have put a lot of work into LMIC, and it has Disco board support… I think it is one (if not the most) of the heaviest supported LMIC libraries out there.
I would make sure that your environment isn’t muddied with other libs that are being called in the build process.

And… this is offered up in complete good-faith, there is a walkthrough that may be of use to you, but specific to the Helium LoRaWAN network: https://developer.helium.com/device/arduino-quickstart

5

There’s being picky, and then there’s being pratical.

Sure, you could probably get the built in capability to work. But if you’re stuck another serial channel is something that could work right away. Getting the goofy seggar scheme to work may not be worth the effort.

First, this is not about just ‘someone else’s’ Arduino core but about the ST Microelectronics supported Arduino Core STM32 which includes support for this board (but does not integrate LoRaWAN support).

LoRaWAN support doesn’t belong in an Arduino BSP in a situation where the application processor directly operates the radio and has to run the LoRaWAN stack. In such a case, the LoRaWAN stack becomes the bulk of your firmware, ie, “sketch” and burying it in a BSP, or even a library, drastically limits flexibility.

Second, this is not an MCCI-Catena board so it is not logical to use their Arduino core that is specificly designed for their boards.

MCCI’s board is just a breakout for the Murata module with some sensors in some configurations, but support for those is probably not in the BSP anyway.

In other words, it’s a sane, working, open source solution or at least starting point for precisely the hardware you are trying to use.