Big STM32 boards topic

Which Arduino core did you use for the STM32F103C?

I just followed the install instructions here.

1 Like

Just noticed that I used 4.12 Volt to Power the STM and the RFM95 through the 3.3V pins (see picture)ā€¦
Itā€™s still functioning after a week or so, but donā€™t try this at home.

Perhaps you can use a LiFePO4 battery. These have a voltage that is a bit lower, about 3.2V. Also they are supposed to be a bit safer than other types of lithium batteries. See also the wikipedia page:

Just quickly, updated ArduinoCore-stm32l0.

LSE is now calibrated via TCXO. This brings RTC close to +/- 1ppm. Was way more than the speced +/- 20ppm on the boards I measured.

Also the PPS pulse out of the GNSS is now hooked up for the GNSS library. It forwards UTC into the RTC (also RTC library), as well as doing phase correction, so that the subseconds of the RTC are aligned with the top of the second coming out of GNSS (CAM-M8Q for Cricket).

Kind of rather nice, if your sensor node is running for a long, long time.

What has not been done (yet) is to apply long term RTC correction via GNSS.

What would also be interesting is to use the Frequency Error feedback of SX1276 to estimate the aging of TCXO. But that implies that the gateway has a more stable clock than the node ā€¦

4 Likes

Which pinmapping are you using for STM32F103?
Currently I am using:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = PA4,
.rxtx = LMIC_UNUSED_PIN,
.rst = PA2,
.dio = {PA3, 1, 2},
};

There is new code for the ArduinoCore-stm32l0:

FskRadio API / Class
LoRaRadio API / Class

Both of them are the first revsision, so things will change.

The LoRaRadio class allows direct access to the SX127x LoRa part of the Semtech radio. Simple async transmit/receive. The receive part implements a packet queue. so that more than one packet can be buffered/processed. CAD is supported as well.

The FskRadio class allows direct access to the SX127X FSK part of the Semtech radio. FSK/GFSK, no OOK. The packet engine allows SyncWord/Length/Address/CRC based filtering. Packets can be up to 255 bytes.

Both classes were done in a way so that they have the same look and feel as the LoRaWAN class. Internally the same radio stack is used for all 3 of them.

There is no documentation yet (no surprise there ;-)), but there are examples to test things out quickly. To get a quick overview over the concept, here the main include files:

FskRadio.h
LoRaRadio.h

Questions and suggestions are welcome.

4 Likes

I got one of the LoRaM3-D F303 boards and am trying for a couple of days to be able to program it from Arduino on a couple of different systems. In all cases Iā€™m running into the basic problem that I donā€™t understand where are the path settings. On Ubuntu it canā€™t find the compiller. On Arch I finally managed to compile the LoRaReceiver sample sketch but it says it canā€™t find dfu-util even though I have a lot of copies of that in various places:

java.io.IOException: Cannot run program ā€œ{path}/dfu-utilā€: error=2, No such file or directory

Does anybody know which ā€œpathā€ itā€™s babbling about and where to set it? If it was using the system $PATH it would surely find it.

I have https://github.com/BSFrance/BSFrance-stm32.git cloned in ~/Arduino/hardware so I would expect that it would try to run ~/Arduino/hardware/BSFrance-stm32/stm32/tools/linux64/dfu-util/dfu-util

I know there is platform.txt (actually there are quite a few of those) but those tend to use relative paths too. e.g. Arduino/hardware/BSFrance-stm32/stm32/platform.txt defines tools.dfu-utilc.path.macosx and .windows but nothing for linux; and those two paths use runtime.hardware.path which I guess is elsewhere; it doesnā€™t seem to be defined in any of the platform.txt files.

Iā€™m not sure whether the BSFrance hardware package is supposed to depend on the official Arduino_STM32 package, but I have that installed too, so there is also Arduino/hardware/Arduino_STM32/STM32F1/platform.txt and Arduino/hardware/Arduino_STM32/STM32F4/platform.txt. And there is a system one: /usr/share/arduino/hardware/platform.txt

I ran into similar problems on Windows.
The BSFrance STM32 Arduino Core on GitHub is incomplete and has some rough edges (I expect that it will not to be updated any soon).
After copying the core from GitHub repository https://github.com/BSFrance/BSFrance-stm32, you will additionally have to copy the ARM tool chain and Arduino tools for STM32 into the coreā€™s directory structure.
IIRC ARM tool chain version 5.x will not work and I think I used version 7.x instead which can be downloaded here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
The STM32 Arduino tools can be downloaded here: https://github.com/stm32duino/Arduino_Tools

In Windows I placed the BSFrance core in Documents\Arduino\hardware\BSFrance-stm32.
I renamed subdirectory stm32 to STM32 to prevent library incompatibility warnings during compilation (related to incorrect casing in library.properties files of certain libraries included with the core).

On Windows the ARM toolchain goes into:
Documents\Arduino\hardware\BSFrance-stm32\STM32\tools\win\gcc
and the tools go into: Documents\Arduino\hardware\BSFrance-stm32\STM32\tools
(Latter with a separate subdirectory per OS. Note: for Linux there are two: linux and linux64.)

You will probably have to tweak one or more paths in platform.txt for dfu-util and possibly for the gcc toolchain.
I donā€™t exactly remember. Have not touched it in months.

For more information on custom(izing) Arduino cores see: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

I have no experience with Arduino on Linux so Iā€™m not sure if there are any OS specific overrides for Linux. The Arduino documentation is not clear about that.
But you can use the versions without OS override (which are the default values) and may add:
tools.dfu-util.path={runtime.hardware.path}/STM32/tools/linux64/dfu-util

All you need will be in your home folder (I guess) in ~/Arduino/hardware (similar to Documents\Arduino\Hardware on Windows). You will need to install it there yourself.
My guess is that on Linux the BSFrance STM32 Arduino core should be put in directory: ~/Arduino/hardware/BSFrance-stm32.

In file ~/Arduino/hardware/BSFrance-stm32/STM32/platform.txt variable {runtime.hardware.path} will point to above directory so you can use it to specify full paths within the coreā€™s directory tree.

The other platform.txt files you mentioned are from other installed STM32 Arduino cores (Roger Clarkā€™s STM32 F1 and F3 Arduino cores, see www.stm32duino.com and Cores).

The world of (names of, supported functionality, compatibility of and references to different) Arduino cores for STM32 is not transparant and confusing. :thinking: :crazy_face: Much different than Arduino for AVR, SAM(D) and ESP32.

3 Likes

Do you have any plans for supporting STM32L1?

(STM32L1 is present on e.g. RAK WisTrio LoRa Tracker RAK5205).

1 Like

The short answer is no.

The long answer ends up in being no as well. L1 is missing a lot of things that L0/L4 have. Like the LPTIM/LPUART peripherals, or the independent clocking for USART / I2C. My interest is really ultra low power setups, and by that L1 is kind of obsolete.

If you are interested in a nice asset tracker, Iā€™d like to point out GNAT. MAX-M8Q, which can track GPS and GLONASS in parallel. BMA400, with a sleep current of 160nA ā€¦

2 Likes

Dear all, I have read the thread but at the end I am not able to understand whether these platforms are easy to use or not with LoRaWAN.
To simplify my question: if I want to substitute a Lora32u4 with one of these, mostly because of memory constraints, which one is ok and easy to make it function (with Arduino IDE possibly)?
Thanks.

If you want to develop with the Arduino framework the problem is that there are many STM32 variants and many are not (or not well) supported with a corresponding Arduino Core.
So if you want to develop with Arduino the choice in STM32 variants that you can choose from is limited. A cheap Microchip AVR alternative is the ā€˜bluepillā€™ STM32 board. It can be used with the LMIC library.
STM32 development with Arduino is not a smooth ride, unless you have a good Arduino Core that supports the specific STM32 MCU you want to use.

@GrumpyOldPizza did a good job porting the SAM(L) Arduino Core to STM32 and he has also ported the Semtech LoRaWAN client (LoRaMac-node) reference implementation (instead of LMIC) but unfortunately his core supports only a select few models of the STM32 family.

Other alternatives for a more powerful MCU than AVR/ATmega32(u4) that are well supported for Arduino development are the Microchip SAM MCUā€™s and the Espressif ESP32. However, there currently exists no common/popular ESP32 (LoRa) boards suitable for low-power applications (if that is what you want). For SAM I donā€™t know.

3 Likes

Thanks - I have played with ESP32 too.
Regarding STM32, I was looking at the BSFrance boards, that are complete for LoRaWAN - I am not sure, but the closest to bluepill seems the LoRaM3-D F103, hopefully this could make things easier.

I have experimented with the BSFrance LoRaM-3D boards + Arduino framework (and have looked into their Arduino core) but for certain reasons BSFranceā€™s support for these boards has been underwhelming.
I have reported several issues almost a year ago but have not gotten any responce since. Also the BSFrance-stm32 Github repository has not been updated since.
A real pity because the LoRaM-3D boards appeared to be a nice addition to existing AVR and ESP32 LoRa boards and are powered with ARM MCUā€™s.

Like existing popular ESP32 LoRa boards, the current version of the BSFrance LoRaM-3D boards were not designed with low-power in mind (even while one of them has STM32 L151 MCU).

1 Like

Ok, you discouraged me :slightly_smiling_face:.

2 Likes

I would have preferred the opposite :slightly_smiling_face:
(good Arduino support from STMicroelectronics for a wide range of STM32 MCUā€™s).

The problem with all of this is that itā€™s rather complex. To deliver something that actually works, you cannot just throw things together quickly.

I had picked STM32L0 because of the Murata module. STM32L1 is kind of obsolete. If you need more horsepower, then STM32L4 would be the pick (and Iā€™ll add support for that one eventually). Itā€™s just not feasible to support everything under the sun.

So what is bad about just picking one of the board with the Murata module and get going ?

1 Like

The Things Network Community is diverse. Part of it is commercially oriented while another part is not, i.e. people who are not getting paid for their TTN adventures (e.g. hobbyists).
For commercial applications it may not be an issue to shelve $40+ for a muRata based board, but for non-commercial applications price is definitely an issue.
Low price is exactly why AVR (ATmega328), ESP32 and STM32 (ā€˜bluepillā€™) based boards have become popular, where prices start at around $1.50 for a board (LoRa support not yet included).