miro EdgeCard
Integration Guide
2. Theory of operation
The miro EdgeCarde implements a standard ACM device (virtual serial character device) for the communcation with the host. The Linux driver needed is cdc_acm. The software stack on the host side, as provided by Semtech and modified by Miromico, consists of two parts: - the HAL library to provide a generic way to access the hardware - the packet forwarder using the HAL, which implements a simple protocol to forward radio packets to a server (and vice versa). Some LoRaWAN network stacks implement their own custom packet forwarder or have a local daemon running to which the packet forwarder connects to. The intention is to mitigate the shortcomings of the Semtech packet forwarder (such as problems with NAT traversal). Hence it is often referred to as "legacy packet forwarder".
3. Initial operation
A first system check should be done with lsusb or /sys/kernel/debug/usb/devices etc. to check for a matching device on the USB bus:
P: Vendor=0483 ProdID=5740 Rev= 2.00
S: Manufacturer=STMicroelectronics
S: Product=SEMTECH PicoGW Virtual ComPortThe Linux driver should have created a /dev/ttyACMx device.
4. Source code
4.1. Notes
Make sure to use the "integration" branch:
git checkout integrationIf you build against libmusl, use the "integration-musl" branch.
4.2. Build
Both components (HAL and packet forwarder) have their own Makefile where $(CROSS_COMPILE) etc. can be set for standalone builds. The HAL layer is built as static library and then static linked in the packet forwarder. As an example for integration in a custom build system, the openwrt directory in the sources holds a Makefile for the OpenWRT distribution.
4.3. Running the packet forwarder
The forwarder has a single configuration file, global_conf.json, which specifies, among others, - the center frequencies of the two radio frontends - the frequency difference to the actual receive frequency for each receive channel - the server host name and port - the gateway id, a "unique" 8 Byte number to identifiy the gateway. This is usually derived with a simple script from the MAC address of the network interface of the gateway. The picoGW_packet_forwarder/lora_pkt_fwd directory holds a few examples of these config files. Example call for global_conf.json in /opt and the gateway card on /dev/ttyACM1:
lora_pkt_fwd -d /dev/ttyACM1 -c /opt(defaults are /dev/ttyACM0 and the current path for the config file)
5. In-System Firmware Update
In order to update or install a custom firmware on the module, the on-board (ROM) bootloader of the integrated MCU is exposed over the interface.
| NRST needs to be connected to a GPIO of the host MCU in order to trigger the update process. Do not connect NRST to the global reset network |
5.1. Update Procedure
The ROM bootloader of the STM MCU integrated with the miro EdgeCard is implementing a DFU protocol over USB DFU class. Detail procedure und protocol is documented in STMicroelectronics AN3156 Application note.
To initiate the firmware update process, the BOOT pin (pin 19) has to be held high while applying a reset pulse to the card on the NRST pin (pin 22). This will force the MCU into bootloader mode and the card will re-enumerate on the USB bus as DFU device. After successfull firmware update, the card needs to be reset again while BOOT pin is held low to start normal operation. For normal operation BOOT pin has to be held low during reset and power up.
5.2. DFU Utility
There is a DFU utility tool available for download. dfu-util is a host side implementation of the DFU 1.0 and DFU 1.1 specifications of the USB forum. DFU is intended to download and upload firmware to/from devices connected over USB.
With any given firmware file in dfu format, the update can then applied with
dfu-util -a 0 -D <file.dfu>