Some updates to F4

I just took a quick look at the F4 and there are several things that I think can be improved straight away,

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));
}

Looking at the F4 code, I think reason that HW serial 1 is not working is that its shared with the OTG USB port, i.e I think that’s the USB host port

I guess perhaps the thing to do is to map Serial to HW serial 2, and use that for debugging

Hi Roger,
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”
——————————

ummm

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

For the __always_inline inline problem, yes, I figured out, I did the merge from Rick, but I’ve never pushed it back to github F4 folder. (I’m apologise here )
This line should be inserted in STM32F4/cores/maple/libmaple/libmaple_types.h at line 50

#define __always_inline inline __attribute__((always_inline))

Martin

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’ve dig a bit further the second issue, I found that I had to comment that line back in May.
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));

Martin

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

Actually, I don’t understand this purely GCC issue, the error message is not meaningful.
Trying to google about it, I only seeing that is parenthesis syntax issue. I hate those bugs ! (they are not in my code )
Maybe Rick expert will bring us light on that ?
How it is working on F1 ? I presume it depend of sketch context …
In the mean time, Funsailor, simply commenting out like I did …

I grabbed the latest github source and when I compile for the STM32 Discovery F407 I get this message:

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


I went ahead and added a variant.h to the STM32F4 for the discovery board.

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


Thanks Rick,

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.

For the variant.h issue, yes, this is a small mistake that I didn’t catch since most of my sketches didn’t include Arduino.h.
Thanks, Rick for catching it and the other !

I will try to update this today.

It slipped my mind yesterday

Martin

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.

@Roger, as I’ve said above, it is a small mistake I didn’t catch on time.
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.

Hi Martin

No Worries

I will action the pull request.

Hi. I’m your average IT, recently I got unemployed so I have some free time to play with a Nucleo F411RE. I’m not a coder, just your typical “I fix your PC” guy, and I wanted to know if there is any bulk work I can do to help supporting this board.

You might want to take a look at https://github.com/sheepdoll/HALMX_Arduino_STM32. This is referenced in viewtopic.php?f=46&t=499.

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.

sheepdoll wrote:Understanding the STM32CubeMx tool should be a good first step for an IT/Coder. It is graphical, runs on all platforms.

I was not looking for what tool shall I use to code as much as helping with the stm32duino port. But if I can help with your branch in any way, I’ll be glad.

Rick Kimball wrote:sheepdoll wrote:Understanding the STM32CubeMx tool should be a good first step for an IT/Coder. It is graphical, runs on all platforms.

madmalkav wrote:I was not looking for what tool shall I use to code as much as helping with the stm32duino port. But if I can help with your branch in any way, I’ll be glad.

I think unless you are a hardened coder that trying to modify the core is going to be a steep learning curve.

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 ?

RogerClark wrote:

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 ?

Will try to look at it in the next days. I’m currently busy with some unexpected home improvement works :/

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

madmalkav wrote:Will try to look at it in the next days. I’m currently busy with some unexpected home improvement works :/

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?

Well, just with that HAL pdf I have reading for some days

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

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