@bluejedi @lorawanhere Ok Guys supposedly native English ‘grunter’ here…now you have me real confused… there was I thinking this (2.0V @ 72Mhz) was a ref to holding voltage steady @ 2V then steadily increasing op freq (say 16Mhz to 32Mhz to 48Mhz…) …up to 72Mhz! 
Tee Hee <VBCG> 
(okay fact the upto is before the voltage vs @ ‘upto’ the freq tells real story but truth is English can sometimes be a bit of a pig I guess )
There was no mentioning of frequencies.
Oh my, there was…
upto 2.0V@72Mhz
I just missed it (my own quote). 
<VBCG> = very big cheezy grin…more a comment on the peculiarities of language & how things can be open to interpretation than the actual statement…smoking? - maybe I should start…
2 Likes
LoRaM3-D boards
Did anyone succeed in getting these boards to work with the LMIC-Arduino library yet?
I have been experimenting with some LoRaM3-D boards but dit not get them to work with LMIC-Arduino yet.
Hangs during call to os_init().
For developing with the Arduino Framework, the boards require the following Arduino core: https://github.com/BSFrance/BSFrance-stm32 (The repo currently lacks some tools, they have to be installed manually. I’m working on things, will post more info later.)
I saw a tip on github to work around some path too long issues: Set temp and tmp environment variables to C:\Temp (not sure if it will help much).
1 Like
LoRaM3-D V1.1 Arduino IDE
With my installation, I found several things missing to compile in Arduino:
In BSFrance-stm32-master/stm32/tools/win/gcc/bin/arm-none-eabi-g++ stuff is missing.
I copied the contents of gcc-arm-none-eabi-7-2017-q4-major-win32.zip from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads to here: \hardware\BSFrance-stm32-master\stm32\tools\win\gcc
Next was about the dfu-util-static which was missing:
Downloaded it: http://dfu-util.sourceforge.net/ and put the dfu-util-static.exe here: \hardware\BSFrance-stm32-master\stm32\tools\win
Finally I was able to compile and upload blink.
The LMIC I have the same problems as were mentioned before by others. The processor freezes when os_init() is called. From the posts above, I cannot understand if there is a solution and which.
Anyone got this resolved and the OTAA-example working?
Issue SOLVED 
(Solution based on @tomtor’s LMIC-Arduino fork.)
The LMIC-Arduino OTAA and ABP examples (ttn-otaa.ino and ttn-abp.ino) are now working with BSFrance-stm32 core with all three BSFrance LoRaM3-D boards:
- LoRaM3-D L151
- LoRaM3-D F103
- LoRaM3-D F303
How to apply the fix:
In LMIC-Arduino src\hal\hal.cpp
Replace:
static uint8_t irqlevel = 0;
void hal_disableIRQs () {
noInterrupts();
irqlevel++;
}
void hal_enableIRQs () {
if(--irqlevel == 0) {
interrupts();
// Instead of using proper interrupts (which are a bit tricky
// and/or not available on all pins on AVR), just poll the pin
// values. Since os_runloop disables and re-enables interrupts,
// putting this here makes sure we check at least once every
// loop.
//
// As an additional bonus, this prevents the can of worms that
// we would otherwise get for running SPI transfers inside ISRs
hal_io_check();
}
}
With:
#ifdef ARDUINO_ARCH_STM32
// Fix for STM32 HAL based cores.
// ARDUINO_ARCH_STM32 appears to be defined for these Arduino cores:
// - Arduino_Core_STM32 (aka stm32duino)
// - STM32GENERIC
// - BSFrance-stm32
// This fix solves an issue with STM32 HAL based Arduino cores where
// a call to os_init() hangs the MCU. The fix prevents LMIC-Arduino from
// disabling and re-enabling interrupts.
// While the exact cause is not known, it is assumed that disabling interrupts
// may conflict with interrupts required for the STM32 HAL core.
// (Possible side-effects on LMIC timing have not been checked.)
void hal_disableIRQs () {
}
void hal_enableIRQs () {
hal_io_check();
}
#else
static uint8_t irqlevel = 0;
void hal_disableIRQs () {
noInterrupts();
irqlevel++;
}
void hal_enableIRQs () {
if(--irqlevel == 0) {
interrupts();
// Instead of using proper interrupts (which are a bit tricky
// and/or not available on all pins on AVR), just poll the pin
// values. Since os_runloop disables and re-enables interrupts,
// putting this here makes sure we check at least once every
// loop.
//
// As an additional bonus, this prevents the can of worms that
// we would otherwise get for running SPI transfers inside ISRs
hal_io_check();
}
}
#endif
4 Likes
Did you ever manage to get lower current in sleep ( ~300uA during full sleep from BSFrance?)
Would really like to get a battery powered device out there; wondering if this is the right board to start with or if we basically must do our own circuits to get rid of the charging circuit/regulator to reduce power when not being used
I have not done any real power measurements yet, but I do know that unfortunately, the current versions of the boards were not designed with low power in mind.
There is a 10k BOOT0 pull-up resistor, normally connected to ground so during normal use it draws a constant current of around 330uA. (Not what is expected from a board that supports to be battery powered.)
There also is a dual 100k resistor divider connected to PA1 for battery monitoring. With a LiPo or Li-Ion battery connected this will constantly draw around 18uA of current (assuming a battery voltage of 3.7V).
Okay good to know. Still trying to decide whether to start with one of these boards or a TTGO V2 
Lowest power seen in this thread for this board: @JTP “1.- Sleep mode: 0.13mA”
Any other lower bidders?
@bluejedi
Pretty cool man, thank you so much! And of course special thanks to tomtor.
It works.
I already tested the [LMIC-arduino by @tomtor (https://github.com/tomtor/arduino-lmic) before but it did not work for me. So, it might be interesting for future users that in his code, he has the condition:
#ifdef ARDUINO_ARCH_STM32F1
which did not work.
I exchanged it for the suggested
#ifdef ARDUINO_ARCH_STM32
and now it does.
1 Like
This will depend on the Arduino core that you use.
Take care with Tom’s LMIC fork. He has disabled the receive Window which is not compliant with LoRaWAN.
And he uses it with Roger Clark’s Arduino_STM32 core, not a HAL based core like BSFrance-stm32, hence the check for ARDUINO_ARCH_STM32F1. Unfortunately different cores do not behave exactly identical.
I have the sample sketches running on a bluepill with Roger’s Arduino_STM32 core and for that I did not have to prevent LMIC disabling interrupts. So I just use LMIC-Arduino as is, without changes. Works with both the OTAA and ABP standard examples. (Possibly Tom has ran into issues that I have not ran into yet.)
@bluejedi
Ok, I will. Thanks for the warning.
I switched over to the LMIC from matthijskooijman and with your modifications, of course it runs.
However, nothing is ever free in the Arduino world: Now, as soon as I add the os_init(); into my code, the u8g2-library stops working. I need to investigate further if I messed something up or if there is a real problem … or use a different library for the OLED.
Tom added some other changes related to STM32 deep sleep. These may be useful also for a HAL based core (but I have not looked at that yet).
I have the normal LMIC-Arduino library (with my above fix) running with BSFrance-stm32 with normally working OLED display using U8g2 on the LoRaM3-D boards.
I plan to post some complete samples that will work out of the box for several boards / MCU’s, including the LoRaM3-D boards (only the TTN related parameters need to be configured).
1 Like
@bluejedi
Very strange. I must be doing something wrong.
What pinmapping do you use then? Did you connect Pin 101 which I interpret as being DIO1?
I connect DIO1 to PB0. Yes the “IO” actually means “DIO” (little space for the text labels).
I use U8x8. SSD1306 hardware I2C constructor.
I only specify the reset pin (check U8g2/U8x8 docs for proper constructor syntax).
SCL and SDA are already defined in the board definition.
Please note BSFrance-stm32 currently has a bug in the F303 board definition. It specifies PB9 for SDA which must be PB7. So you must either specify SCL, SDA and Reset in the U8x8 constructor explicitly or fix the board definition.
Also note that the LED is ON when HIGH (current F151 and F103 board definitions incorrectly indicate that LOW is ON which is not true).
2 Likes
Wow. You are a genius! Not specifying the SDA and SCL Pins (leaving SDA, SCL in) did the trick.
I thought it does not matter as without the os_init() it worked like that:
U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, /* clock=/ PB6, / data=/ PB7, / reset=*/ PB5);
But with it only works with:
U8G2_SSD1306_128X64_NONAME_F_SW_I2C u8g2(U8G2_R0, /* clock=/ SCL, / data=/ SDA, / reset=*/ PB5);
U8g2 and U8x8 constructors
For the display on the BSFrance LoRaM3-D boards, the following U8g2 and U8x8 constructors can be used (they use hardware I2C).
Tip: Use default values / automatic configuration where possible.
For U8x8:
// No need to specify SCL and SDA, the default values
// are already defined in the board definition.
U8X8_SSD1306_128X64_NONAME_HW_I2C display(/*reset*/ PB5);
// This is in fact identical to the above.
U8X8_SSD1306_128X64_NONAME_HW_I2C display(/*reset*/ PB5, /*clock*/ SCL, /*data*/ SDA);
// Same as above but explicitly specifies the GPIO ports to use for SCL and SDA.
U8X8_SSD1306_128X64_NONAME_HW_I2C display(/*reset*/ PB5, /*clock*/ PB6, /*data*/ PB7);
For U8g2 (using full buffer):
// No need to specify SCL and SDA, the default values
// are already defined in the board definition.
U8G2_SSD1306_128X64_NONAME_F_HW_I2C display(U8G2_R0, /*reset*/ PB5);
// This is in fact identical to the above.
U8G2_SSD1306_128X64_NONAME_F_HW_I2C display(U8G2_R0, /*reset*/ PB5, /*clock*/ SCL, /*data*/ SDA);
// Same as above but explicitly specifies the GPIO ports to use for SCL and SDA.
U8G2_SSD1306_128X64_NONAME_F_HW_I2C display(U8G2_R0, /*reset*/ PB5, /*clock*/ PB6, /*data*/ PB7);
Have you tried the constructors described in above U8g2/U8x8 constructors post? These constructors should all work (tested on F103).
I have no access to my F103 the coming week but I will try and post the result. SW I2C worked but HW would be better, obviously.