Big STM32 boards topic

(Sandgroper) #144

Which Arduino core did you use for the STM32F103C?

(Edzelf) #145

I just followed the install instructions here.

(Edzelf) #146

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 …

(Flip) #149

Which pinmapping are you using for STM32F103?
Currently I am using:
// Pin mapping
const lmic_pinmap lmic_pins = {
.nss = PA4,
.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:


Questions and suggestions are welcome.

(Ecloud) #151

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: 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 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

(Ecloud) #152

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, 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:
The STM32 Arduino tools can be downloaded here:

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 files of certain libraries included with the core).

On Windows the ARM toolchain goes into:
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:

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:

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 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.