Firstly its missing the enum that maps pin names e.g PA0 to he PIN_MAP[0]
Also the compiler is being set as cortex-m3 but the processor is a cortex-m4
I’ve tried changing this and it still seems to compile OK.
One thing I have noticed is that sometimes it doesn’t run after the upload via STlink,
I thought this could be because I switched to cortex-m4 and that the compile had failed, but I pressed the reset button and it had uploaded OK
and the next upload was OK
So I think its something in the stlink uploader that is intermittent.
I have swictched to an open source uploader (Texane-stlink) instead of the STM proprietary uploader but its the same one as we use on all platforms on the F103, so it should be OK.
Re: Serial
Yes.
Very odd. I’m not sure why Hardware Serial doesn’t seem to work. As far as I can tell its being initialised and setup etc, but its definitely not working
HW serial 1 is connected to the OTG USB port, so I wonder if I damaged it by connecting it to my PC at some time, but if its not working for you either. Then perhaps we have both tried connecting OTG to the PC or its a different problem
Anyway, I will push the change to the repo, so that sketches like this work
void setup() {
// put your setup code here, to run once:
//Serial1.begin(115200);
Serial2.begin(115200);
//Serial3.begin(115200);
//Serial4.begin(115200);
pinMode(PD12,OUTPUT);
pinMode(PD13,OUTPUT);
pinMode(PD14,OUTPUT);
pinMode(PD15,OUTPUT);
}
int c;
void loop() {
// put your main code here, to run repeatedly:
//Serial1.println("Serial");
Serial2.println("Serial1");
//Serial3.println("Serial2");
//Serial4.println("Serial3");
toggle(PD12);
toggle(PD13);
toggle(PD14);
toggle(PD15);
delay(250);
}
void toggle(int pin)
{
digitalWrite(pin,!digitalRead(pin));
}
I guess perhaps the thing to do is to map Serial to HW serial 2, and use that for debugging
now I test a STM32F4 Discovery.
I check in the actual gitub version and have this Problem:
C:\Arduino\hardware\Arduino_STM32\STM32F4\cores\maple/libmaple/spiF4.h:78:8: error: ‘__always_inline’ does not name a type
static __always_inline void spi_gpio_cfg(uint8 as_master,
and
c:\users\mikel\appdata\roaming\arduino15\packages\arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\stdlib.h:67:5: error: expected unqualified-id before ‘int’
int _EXFUN(abs,(int));
any idea?
-> in the file
..\STM32F4\cores\maple\arduino.h
is the wrong include “variant.h”
I set this in comment
——————————
#ifndef Arduino_h
#define Arduino_h
#include “WProgram.h”
#endif
//#include “variant.h”
——————————
__always_inline is a one of the issues on the To Do list.
I thought from what Rick Kimball has written that this is a built in name inside gcc
perhaps its a typo.
The best person to ask is @martinayotte as he has done all the recent changes in the F4 repo.

This line should be inserted in STM32F4/cores/maple/libmaple/libmaple_types.h at line 50
#define __always_inline inline __attribute__((always_inline))
Thanks.
I’ve directly updated that source (edited the file on GitHub)
Hopefully that will fix one of the issues, but I agree, I’m not sure whats going on with the other issue.
Perhaps if the OP tries with the change for __always_line the other issue may go away (but probably not )
I don’t understand the real issue, but simply commenting it solved it.
arduino\tools\arm-none-eabi-gcc\4.8.3-2014q1\arm-none-eabi\include\stdlib.h:67:5: error: expected unqualified-id before 'int'
int _EXFUN(abs,(int));
Thanks
I recall seeing errors with EXFUN() before, but I cant recall what i did to overcome them.
I think possibly that i saw similar issues when making some other changes, ( to the F1), but suspect i didn’t end up implementing the changes, due to the EXFUN() issue.
This problem, may be something that Rick has also come across, as he has explored building with different IDEs etc.
But I think its best for the OP to get back to us first, in case they solved their own problem
Trying to google about it, I only seeing that is parenthesis syntax issue. I hate those bugs !


Maybe Rick expert will bring us light on that ?
How it is working on F1 ?

In the mean time, Funsailor, simply commenting out like I did …
/home/kimballr/.arduino15/packages/arduino/tools/arm-none-eabi-gcc/4.8.3-2014q1/bin/arm-none-eabi-g++ -c -g -Os -w -MMD -ffunction-sections -fdata-sections -nostdlib --param max-inline-insns-single=500 -fno-rtti -fno-exceptions -DBOARD_discovery_f407 -DVECT_TAB_BASE -DERROR_LED_PORT=GPIOD -DERROR_LED_PIN=14 -mcpu=cortex-m4 -DF_CPU=168000000L -DARDUINO=10606 -DARDUINO_STM32F4_DISCOVERY_F407 -DARDUINO_ARCH_STM32F4 -DMCU_STM32F406VG -mthumb -DSTM32_HIGH_DENSITY -DSTM32F2 -DSTM32F4 -DBOARD_discovery_f4 -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple/usbF4 -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_Device_Library/Core/inc -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_Device_Library/Class/cdc/inc -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple/usbF4/STM32_USB_OTG_Driver/inc -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/libmaple/usbF4/VCP -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple -I/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/variants/discovery_f407 /tmp/build1716864136632058487.tmp/sketch/sketch_jul24a.cpp -o /tmp/build1716864136632058487.tmp/sketch/sketch_jul24a.cpp.o
In file included from sketch_jul24a.ino:1:0:
/mnt/vbox/shared/Arduino_STM32RK_Sketch/hardware/stm32duino/STM32F4/cores/maple/Arduino.h:6:21: fatal error: variant.h: No such file or directory
#include "variant.h"
^
compilation terminated.
Error compiling.
Then I get the error you guys are seeing. It seems to me that wirish.h should be including stdlib.h before anything else… I added it and then everything compiles properly:
in wirish.h
....
#ifndef _WIRISH_H_
#define _WIRISH_H_
#include <stdlib.h>
#include "libmaple.h"
....
I will update the repo.
I’m not too sure how this issue came about, I presume it was an unexpected consequence of one of Martins pull requests, as i have not done any changes to the F4 folder for quite some time.
Thanks, Rick for catching it and the other !
It slipped my mind yesterday
arrggghhhh!! The F4 side of the repo seems to be completely broken.
Arduino.h is trying to include variant.h but that file doesn’t exist.
Do you have some files on your machine which you didn’t push to the server before doing the a pull request ??
It looks like you added the include in this commit
https://github.com/rogerclarkmelbourne/ … 2a8e4c3fd5
Thanks Roger
PS. No point in me updating the file to include stdlib until this major problem is resolved.
I’ve simply forgotten to add this file in the repro, it is a copy from F1, like all the others.
I’ve now added and sent you a PR for that.
No Worries
I will action the pull request.
HALMX is more of a “quickstart” approach. Instead of “programming” the device a tool called STM32CubeMx from ST is used to generate the boilerplate code. I do not have the Nucleo411RE, I have the Nucleo401RE. It would not be too difficult to add the Nucleo411RE, core. Using the existing Nucleo401RE as a template. Even though I do not have the Nucleo411RE hardware. I plan to add this core in the near future.
Understanding the STM32CubeMx tool should be a good first step for an IT/Coder. It is graphical, runs on all platforms. The ‘boilerplate: code can also be run under a wide variety of IDEs. Many which support On chip debugging (OCD.) I may also suggest learning the Eclipse IDE tool. OpenSTM and openOCD are places where there need to do a lot of bulk work. I use OSX, other OS platforms (Like Windows) are a bit more mature but the Windows OS is no longer hardware stable. Linux is the future as more mainstream companies return to the 1950s model of renting computers and selling time.
If you want to get the F4 Nucleo working, its hard choice, because from what I recall the Nucleo F103RB board has a load of specific config stuff which Matthias had to write to get it to work with the F1 Maple core.
You’d be best off PM’ing @madias and asking him the quirks of the Nucleo
So, I have a feeling that working with @sheepdoll’s latest core may be worth looking at, rather than trying to hack the Maple F4 (aka AeroQuad) core to work with the Nucleo F4
But of course there are no libraries yet for @sheepdoll’s core. So perhaps writing the SPI library for that core would be a good use of time ?
But of course there are no libraries yet for @sheepdoll’s core. So perhaps writing the SPI library for that core would be a good use of time ?
By the way, I still need to understand how all that sea of stuff interrelate between. I thought CubeMX was just a GUI for making the MCU initialization code easier, and the HAL are some ST provided libraries to use against standard GCC-ARM?
And you are writing a layer to use that stuff with standard Arduino stuff, but libraries needs to be ported, right? So we must look for STM32 libraries like this and adapt them to the Arduino standard?
As you can see there is some stuff I still need to glue in the correct order in my head…
PS: I confess I have been playing a little with the mBed stuff, but don’t take me for a traitor
By the way, I still need to understand how all that sea of stuff interrelate between. I thought CubeMX was just a GUI for making the MCU initialization code easier, and the HAL are some ST provided libraries to use against standard GCC-ARM?

(By the way, I didn’t had problems with mbed online or exported, perhaps a macosx thing?)