Implement a secure ICS protocol targeting LoRa Node151 microcontroller for controlling irrigation.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
 
 
 

3.0 KiB

Notes

This file contains various notes about the development of this repository.

This is based upon the PingPong code from Heltec for Node 151[1].

The STM32Cube packages are undocumented as far as I can tell. Various files were copied from the PingPong code.

MIT licensed code for the SX1276 is available at https://github.com/HelTecAutomation/Heltec_ESP32/tree/master/src/lora .

BSD licensed code for the SX1276 is available at https://github.com/Lora-net/LoRaMac-node . It includes support for the STM32 micros, and so was used as the basis. Biggest issue is that it adds yet another HAL layer to the whole thing.

mscgen for message diagram generation

ECDH: https://tools.ietf.org/html/rfc7748#section-6.1

Command to find and copy various files into the tree. Almost all files were pulled from the STM32CubeL1 tree, but there was one or two that was pulled from LoRaMac-node tree.

cp $(find /tmp/Pingpong_CDC/ -name cmsis_gcc.h) stm32/

The following command can be used to strip CR’s, and to remove any trailing new lines. Note that in order to save my sanity, the files are committed after cleaning. The repo does NOT contain (if it can be avoided) the pre-cleaned files. The diff options -w -b may be used to ignore these cleanups.

# there is a ^V^I and a ^V^M in the following:
LANG=C sed -i '' -e 's/[       ]*^M$//' $(find stm32/ -type f)

Unix dgram sockets

By default, unix dgram sockets are not bound, which means that when a client sends to a server, there is no return path. A client can bind to a local address, and this address will be received by the server allowing the server to reply.

Unix dgrams sockets do not support broadcast, so a server would have to keep track of all the clients, and send any packets to each client individually, which is fine for a small number of clients.

Using broadcast or multicast IP pushed this work to the IP layer.

Running gdb

First, just run openocd, but w/o any needed command, or you can reset it:

sudo openocd -f interface/ftdi/digilent-hs1.cfg -f interface/ftdi/swd-resistor-hack.cfg -f target/stm32l1.cfg -c "init" -c "reset init"

Then run arm-none-eabi-gdb with the elf binary, and attach to OpenOCD with the command:

target remote localhost:3333

The gdb monitor command allows control of the device. For example:

monitor reset halt

will reset the device, and halt it immediately, allowing setting a break point for main, or earlier.

Weird Handlers

When using gdb you might end up in a weird handler that is unexpected. This is because the DefaultHandler will not always be obvious, use the following command to generate Handlers for all the weak ones to figure out which is the correct handler being hit:

arm-none-eabi-nm build/rs485gw.elf  | awk '$2 == "W" && && $3 != "Reset_Handler" && $3 ~ /Handler$/ { print "void " $3  "(){ for(;;); }" }'

[1] https://heltec-automation-docs.readthedocs.io/en/latest/stm32/lora_node_151/pingpong_test.html