Well, I guess I'm just talking to myself. I must be the only one running into this right now.

I did manage to fix it, but it's a bit of an ugly way to do it. I've compared the code for different frameworks in platformio, and I haven't really figured out why it fails on STM32, but not the others I've tried. No, I haven't exhaustively tried them all.

In the .platforio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp file it's really almost completely empty. But then, so is the one from MySensors, though it has one addition for serialEventRun. Interestingly, other frameworks through platformio have this line as well, just not this one.

Anyway, the MySensors one has that extra, so I commented out the maple one through platforio, and then it lets the compilation complete. I haven't gotten far enough to know for sure that it doesn't cause further problems down the line, but I hope this is progress, and I wanted to get it written down while it's still fresh in my mind.

Sorry about all the replies, but I just remembered one more thing. I was using the current version of MySensors, but I also then switched to the development branch, just to see if it changed anything, but that also didn't do any good. (Didn't do any harm, either.)

Oops, here's the file with code and the results of my attempts to run it.

https://drive.google.com/open?id=1AeKD9PoyGAzp1cw4GjS_jqQ1IIVEpWeu

I should also mention, that I've tried this on different computers - a couple different Windows 10 machines, as well as running on an Ubuntu CLI machine. I get the same results on all three.

Well, I ran into a new problem. Platformio is complaining that there are multiple instances of 'main.cpp' when I try to compile for this board. I've tried a couple different variants, but they all end up using the STM32F1 section of the HAL, and they all fail the same way. I've also tried with a NRF51 target, as well as an ATMEGA328p target, and they worked fine.

I've got it down to an absolutely empty file, with just declaring that I want the RFM69 radio and #including the Mysensors.h file. (I was actually a little surprised that the NRF51 target didn't mind me using the RFM69 radio... but I didn't really have any code actually attempting to send it any commands, so that might have thrown errors down the line.)

I included the results of trying to compile the code. Strangely, the result of -v seemed to be much less verbose than leaving it off. If there's anything else needed to help diagnose this, I'll do whatever I can. If there are developers here who can point me the right direction, I can also try to fix the underlying library, if it's not in fact me just missing something incredibly obvious. I also don't know how to tell if the problem is in the Mysensor code, or the underlying support libraries for the STM32 platform. But there are others here using it, right? So I might have done something silly...

Anyway, thanks in advance for any help!

I know this an old topic now, and I don't know if this would still help you @otousset, but I ended up running across this while searching for a solution, as I had the same problem. I finally found the solution at this page: https://docs.platformio.org/en/latest/platforms/ststm32.html

What it comes down to is that there are two different 'Arduino' cores with platformio, and we have to use the 'maple' one, which has the libraries in the format that the MySensors expects to see. The line:
board_build.core = maple
has to be added to the platformio.ini file in the project folder, which switches the core to be what MySensors framework needs. Then I got it to compile without complaint. (Well, but I guess I haven't actually finished my installation to be sure that it works with the gateway...)