stm32f103c8 problem at compilation

[otousset]

Hi,
I'm using arduino and platformio and I have the same problem.
I'll talk about arduino 1.8.7.
I have installed from https://github.com/stm32duino/BoardManagerFiles/raw/master/STM32/package_stm_index.json
the package "STM32 Cores by STMMicroelectronics version 1.5.0" for board "BluePill F103C8"
I have installed the library "MySensors by The MySensors Team Version 2.3.1"
And I have this error

Build options changed, rebuilding all
In file included from I:\ARDUINO\ARDUINO-1.8.5\OTO-DOCUMENTS\libraries\MySensors/hal/architecture/STM32F1/MyHwSTM32F1.cpp:20:0,
from I:\ARDUINO\ARDUINO-1.8.5\OTO-DOCUMENTS\libraries\MySensors/MySensors.h:69,
from C:\Users\oto\AppData\Local\Temp\arduino_modified_sketch_62106\sketch_feb21a.ino:44:
I:\ARDUINO\ARDUINO-1.8.5\OTO-DOCUMENTS\libraries\MySensors/hal/architecture/STM32F1/MyHwSTM32F1.h:23:27: fatal error: libmaple/iwdg.h: No such file or directory

 #include <libmaple/iwdg.h>

compilation terminated.

exit status 1
Error compiling for board Generic STM32F1 series.

Can anyone help me ?
Thanks !

[ejlane]

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

[ejlane]

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!

[ejlane]

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.

[ejlane]

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

[ejlane]

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.

[leroyl]

@ejlane, nope your not going around the bend...
I've just started playing with Platformio and decided to try the BluePill/MySensors combination with Platformio and ran across your posts.
I also hit the same problems with multiple defines for main() and premain(). You might declare the functions "weak" in the Platformio Arduino framework version of main.cpp, as long as the second implementation accomplishes the same thing that is. The linker should allow the override if a second version is defined.

So platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp would have the attrubute ((weak)) added to the function defines as:

 
__attribute__(( constructor (101)))  __attribute__ ((weak)) void premain() {
...  
}

__attribute__ ((weak)) int main(void) {
...
}

Dislaimer: Compiles but I cannot find my BluePill to actually execute...

And: Thanks for the "board_build.core = maple" tip

[ejlane]

@leroyl huh, I've never used a weak attribute before. It looks like it's made for just this situation. Thanks for the tip!

I still think this is a bit of an ugly hack - having to mess with a library. I'd rather that it was included upstream, of course. But your solution is far better than mine, so thank you, I appreciate it!

[leroyl]

EDIT: Turns the below workaround does not work as I had expected so ignore it. I'll remove this note when/if I have it correct.

@ejlane I've poked at this a bit further.
I believe why the Arduino IDE builds succeed is because the main.cpp in question at arduino/hardware/Arduino_STM32/STM32F1/cores/main.cpp is put into a library archive (.a) prior to being passed to the linker thus no redefinition conflict.

Within the Platformio builds this archiving is "not" done, the ./STM32F1/cores/*.o files (main.cpp.o) are passed directly to the linker along your application .cpp file.

Your app .o file contains the premain() and main() symbols it obtained from when it included the MySensors header file and by extension MyMainSTM32F1.cpp and all the other MySensors code.

So now we have two files containing the same symbols being passed directly to the linker, your app .o and main.cpp.o hence the conflict.

NOTE: This next is the part that does not work. The src_filter syntax is not correct, this results in the src/* files being ignored so it just "seems" to compile. You will probably have unresolved setup() and loop()

Now the good news. There is a work around you can add to your platformio.ini file such that you "may" not need to modify the platformio library. Add the following to you env define:

src_filter= -~/.platformio/packages/framework-arduinoststm32-maple/STM32F1/cores/maple/main.cpp

The - (minus) says to "not" include this file in your build. Just be sure you are not loosing any needed functionality that may be within this file now that it is ignored.

I'll still follow up with the Platformio folks to try to determine what the best final solution is.

[Peter Feerick]

Odd... I thought I had an account here... must just have been a long-time lurker!

As I mentioned over on the PlatformIO forum, it's a relative path... and whilst it can be made to compile... I don't like the look of warning that was given during linking.

Some digging will be needed to figure out why AVR successes but STM32 fails, as IMO they should both have failed miserably during the compile.

[leroyl]

@peter-feerick, thanks for opening the issue over at the Platformio forum. FYI for others:
The Platformio ticket

[Peter Feerick]

I haven't tried this yet, but "mtiutiu" replied to the issue on GitHub, and suggested a script that would basically automatically add the __attribute__ ((weak)) during the compile. Sounds like a promising temporary workaround