NUCLEO-L476RG + Eclipse on Gnu/Linux

[ea_man]

To day I got as a present a new Nucleo Board NUCLEO-L476RG and I'm going to use it on a Debian Sid 64bit with Eclipse: I could use some help to set up the tools.

So far I have working

- STM32CubeMX
- STLINK2 (well it works, I don't have anything to test it)
- Eclipse C/C++ Version: Mars.1 Release (4.5.1)
- GNU ARM Eclipse plug-ins
- crossbuild-essential-armhf : all the arm-linux-gnueabihf-*
- OPENOCD + GDB + Qemu-static

At the moment I'm able to compile some C++ for an OrangePC (it's like a raspberrypi): arch is armhf , ARMv7 Processor rev 5 (v7l) . I can compile, local test with Qemu, upload via SSH and debug it on the board with GDB.

First thing I have to know: this Nucleo64 board needs  crossbuild-essential-armel ?
Nucleo NUCLEO-L476RG has a CPU STM32L476RG: Ultra-low-power with FPU ARM Cortex-M4 MCU 80 MHz, this should be a Cortex M4, Arch: ARMv7E-M
As for ports this should be armhf _if_ I get it right.
- https://www.debian.org/releases/stable/armhf/ch02s01.html.en

I've seen that there's a Eclipse plugin providing templates for STM32Fx boards, is there something around that could work for my board?
 In case not could anyone point me in the direction to boostrap a first Blink to test the board?

All I see around are tutorials for the STM32Fx line...

Disclaimer: I'm a noob, first time at STM32 but here are my notes if you care:
- http://notes.andreamanni.com/arm_en.html

[Brutte]

Cannot help with cross compiler on linux (I am a windozer, I am using gcc-arm-embedded ).
I also assume you are able to compile printf("hello world"); with a native compiler or debug with OpenOCD and gdb under Eclipse control.

If you pick a "Hello_World C project" wizard in "GNU ARM plugin for Eclipse" it should work fine out of the box (select "Cortex M3" core and "stm32l4xx.h" as CMSIS name of your uC). Default project settings do not run uC at full throttle and not all IRQs are listed but you definitely do not need that or any peripherals libraries for a semihosted "Hello World".
I'd suggest:
 1. you double-check your *.ld if flash is at 0x08000000 and SRAM is at 0x20000000.
 2. overcopy the stm32l4xx.h stub with the one from ST (it is a vendor's duty to provide that file).

Once you debug the project, you should get a "Hello World" in an OpenOCD console in Eclipse.
When you get proficient in semihosting, you can try out a coprocessor, 80MHz operation, peripherals and other goodies.

[ea_man]

Thanks Brutte, I'm reading about  that.

But first I'm wondering if my path of using this board with STMCube MX (RTOS + HAL) is sound as the framework has quite an ugly reputation around and ST doesn't give a shit about doesn't target  people like me who want to use free software / GCC / Linux.

As far as I'm understanding maybe it would be better for me to use FreeRTOS + libopencm3 , yet I'm not sure that these are in a state as mature as a beginner would need (sorry but I'm not even able to carve a makefile and an initialization setup out of this ST* madness, I'm not yet equipped to work on a port).

An other path could be the good work of Baoshi:
- http://www.ba0sh1.com/stm32cubemx-gcc-makefile/
- http://www.ba0sh1.com/opensource-stm32-development/

This seem on spot but maybe I should cut my teeth on a MSP432 first as I can have an "almost decent" environment with CSS.   

And NO, I'm not interested in Mbed, that's worst than MySQL and Android: at least you can fork those.

So the hardware is very appealing with 1MB of RAM for a RTOS but I find the environment quite hostile. I mean: it took me 15minutes to have a cross build environment + local and remote debugger for my Orangepy PC, two days on this Nucleo and I'm not even confident about where I should go. Heck I'm going to use [Eclipse | Vim + Makefile] + GCC this is as standard as it gets where I come from.

[Brutte]

the framework has quite an ugly reputation around and ST doesn't give a shit about doesn't target  people like me who want to use free software / GCC / Linux.

The only comparable HAL for STM32 that I know of is from ChibiOS. It is very generic thus does not support all bells and whistles available in STMs.

As far as I'm understanding maybe it would be better for me to use FreeRTOS + libopencm3

FreRTOS does not provide HAL for STM32, it is only OS. libopencm3 is not HAL. It is just a generic peripheral library and it does not provide the abstraction layer for concurrent sharing of peripherals (no os support).

sorry but I'm not even able to carve a makefile and an initialization setup out of this ST* madness

There is nothing particularly interesting in makefile that relates to ST libraries. The only difference between bare metal and CubeMX is perhaps "-lstm32cubemx" that needs to be included at linking stage, but that is about it. Not sure what you expected.

Usually people start from "HelloWorld.txt" but you insist on starting with "HelloWorld.mp4"

And NO, I'm not interested in Mbed, that's worst than MySQL and Android: at least you can fork those.

What is Mbed?

So the hardware is very appealing with 1MB of RAM for a RTOS but I find the environment

[ea_man]

Thanks  again Brutte, I'm looking into ChibiOS and FreRTOS.

The only difference between bare metal and CubeMX is perhaps "-lstm32cubemx" that needs to be included at linking stage, but that is about it. Not sure what you expected.

A template for HelloWorld for STM32L4 that I can run in Eclipse or even better a blink.tar.gz that I can just make ; make upload (or st-flash) and then understand from it what I need to make my own. I don't care about abstraction right now, first I need something that works, HAL or bare metal or in between. I guess that SPL is the common rule.

Usually people start from "HelloWorld.txt" but you insist on starting with "HelloWorld.mp4"

My problem is that i only got GutenTag.txt:

Code: [Select]

../system/include/cmsis/core_cm0.h:146:6: error: #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
../system/include/cmsis/cmsis_gcc.h:81:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
system/src/stm32f0-stdperiph/subdir.mk:21: recipe for target 'system
The only examples for HelloWorld.cpp that I've found are for STM32F* and I can't adapt those for my board wich is ARMv7E-M with a FPU so it should go with a armhf compiler, do I have to install crossbuild-essential-armel for armel in order to have those g++-arm-linux-gnueabi and forget about my FPU?

Then I have the <HelloWorld ARM C++ Project> from Eclipse wizard but then I'm not able to integrate into it the "uc conf" that CubeMX is supposed to give me.

What is Mbed?

- https://www.mbed.com/en/

So the hardware is very appealing with 1MB of RAM for a RTOS but I find the environment

So what's the point of having 1MB of Flash  if you are not running a whole "OS" on it?
I've been fine with ~32kb of Flash until today...

[ea_man]

Whoot I made a step ahead: I found that I did not have any Gnu ARM Packs ( http://gnuarmeclipse.github.io/plugins/packs-manager/ ) installed so I was not able to choose much of my CPU. Now there are no specific packs for my board L4, I'm trying to make something up from the Cortex generic hello world.

[MT]

I find the environment quite hostile. I mean: it took me 15minutes to have a cross build environment + local and remote debugger for my Orangepy PC, two days on this Nucleo and I'm not even confident about where I should go.

Only 15 min!  You are lucky! If you get tired with your eclipse build:
http://www.emblocks.org/web/

[ea_man]

I find the environment quite hostile. I mean: it took me 15minutes to have a cross build environment + local and remote debugger for my Orangepy PC, two days on this Nucleo and I'm not even confident about where I should go.

Only 15 min!  You are lucky!

Well you know, they both run the same OS

If you get tired with your eclipse build:
http://www.emblocks.org/web/

Yep that's what I've been using to test the board, It's not my cup of tea but at least it works out of the box.

[nctnico]

OTOH: If something works in 15 minutes you don't have any clue what happens under the hood. 

[ea_man]

OTOH: If something works in 15 minutes you don't have any clue what happens under the hood. 

I know how the build chain works, the repos, package manager and all the tools because they are all the same from an embedded to a multicore Xeon to a cluster of x86. That's the point of having the same tools, in this case it's the very same distro, running on everything, that's why I want to keep on this boat and not jump on some proprietary / closed solution.

[andersm]

First thing I have to know: this Nucleo64 board needs  crossbuild-essential-armel ?

No, those are for crosscompiling to ARM-based Linux systems. To enable floating-point code generation, you have to select the FPU type (-mfpu=fpv4-sp-d16) and ABI (probably -mfloat-abi=hard). If you use the GNU ARM Eclipse plugin, you can use the C/C++ Build Settings dialog in the project properties to configure code generation.

[ea_man]

Thanks andersm, I was actually looking fot the correct FPU type for my CPU. Tomorrow I will try.

BTW: I'm not sure that I got right what you said about cross compiling: right now I don't have crossbuild-essential-armel because I installed just crossbuild-essential-armhf.

That's because I'm running a rolling distro (I have GCC 5.3.1-4cross1 ) and I'd rather stick with my distro GCC (security, updates, integration) instead of doping my system with *mainstream staff.

[andersm]

BTW: I'm not sure that I got right what you said about cross compiling: right now I don't have crossbuild-essential-armel because I installed just crossbuild-essential-armhf.

All the crossbuild-* packages are for compiling code for Debian Linux running on another architecture. They're useless for a microcontroller board like the Nucleo. The gcc-arm-none-eabi package installs a bare-metal ARM toolchain, which I believe is derived from the GCC ARM Embedded distribution.

[ea_man]

Got it, thanks for the clarification.

So gcc-arm-linux-gnueabihf is for OrangePI PC / RPi (they run Gnu/Linux), for ARM Cortex A/R/M it's gcc-arm-none-eabi .

- Debian now has:  arm-none-eabi-g++ (15:4.9.3+svn231177-1) 4.9.3 20150529 (prerelease)
- Mainstream @ GCC ARM Embedded:  arm-none-eabi-g++ (GNU Tools for ARM Embedded Processors) 5.2.1 20151202 (release) [ARM/embedded-5-branch revision 231848

BTW: I see that others (Arduino, Texas Instruments) are running on 4.8.4 so maybe 4.9.3 ain't that bad.

[nctnico]

You can always download the tar archive and dump it somewhere in a bin directory. That is how I installed GCC on my Debian machine. The last thing you want is to depend on the Linux distribution to tell you which GCC you are going to use for embedded work.

[ea_man]

You can always download the tar archive and dump it somewhere in a bin directory. [CUT]

Thanks, I've done that.

As matter of fact now I have like 5 different tool chains as each IDE for Arduino, Energia, STM32, TI tends to download their  own set of GCC.
I don't like that, I wish I could have one solid installment of GCC on my OS taken care by my distro maintainers and each damm IDE takes from there.

I have a lab with 20 PC to manage and I don't like the idea of having 4GB on each box to do the same thing in 5 different version.

[andersm]

As matter of fact now I have like 5 different tool chains as each IDE for Arduino, Energia, STM32, TI tends to download their  own set of GCC.

As I've said several times in other threads, don't use vendor IDEs unless you absolutely have to. Sometimes you're forced to, because of special features (eg. Cypress PSoC) or proprietary interfaces (eg. most Renesas devices), but there's absolutely no point for some generic STM32 or MSP432 device.

I don't like that, I wish I could have one solid installment of GCC on my OS taken care by my distro maintainers and each damm IDE takes from there.

While it would be convenient, relying on distro-maintained toolchains would be risky as nctnico explained. In any case, Debian has a reasonably up-to-date AVR GCC that seems to be based on Atmel's releases, but the MSP430 package is based on the old mspgcc project, which was abandoned when TI took over maintenance duties of the port themselves.

[dannyf]

I have like 5 different tool chains as each IDE for Arduino, Energia, STM32, TI

I have consolidated my tool chains to Keil / IAR / CoIDE - any of them would have done it for me but having a little bit variety doesn't hurt.

You could install Windows on your Linux version and go from there -> that's how many embedded developers develop on Apple machines.

[ea_man]

I have like 5 different tool chains as each IDE for Arduino, Energia, STM32, TI

I have consolidated my tool chains to Keil / IAR / CoIDE - any of them would have done it for me but having a little bit variety doesn't hurt.

You could install Windows on your Linux version and go from there -> that's how many embedded developers develop on Apple machines.

Thanks I will look into that.
But it's not an option where I work 'cause we do only free (as in freedom) software, as for ex. if PSoc doesn't work on Linux -> No PSoc. This year I do Arduino, AVR, STM32duino, Tensey, *ESP8366 and of course all the embedded that it's Linux based: there's more than enough, I have a couple of PSoc on my desk and other things but they are just  divertissement.

No way that I'm fucking up an environment stable, safe and with _no_license_issues_ with a Windows VM and a 6GB of binary software for each IDE.

[dannyf]

A "stable, safe" OS has never existed and probably never will. You may not know its vulnerabilities or it may not have been attacked. But that doesn't make it safe.

As to licensing issues, I am not aware of any licensing issues with the tools or Windows.

But if your goal is to only work with "free" software, many of the commercial tools are out of reach and you may have to put up with the consequences of using "free" software / environments.

To me, I make a living off of those tools so those "free" tools are simply too expensive for me.

[mcmayer]

Carmine Noviello has a a good blog about the STM32 family http://www.carminenoviello.com/en/2015/06/04/stm32-applications-eclipse-gcc-stcube/ and he started a book "Mastering STM32" on leanpub.com: https://leanpub.com/mastering-stm32. It is 40% complete as of 2016-01-23.
I just bought the e-book and I quite like it. The English is not 100% polished, yet, but I don't care as long as the content is good - which it is.

To the topic: Chapter 4 explains how to use the STM32CubeMX tool to create a Eclipse project for any of the STM32 Nucleo boards. Since Eclipse doesn't have the L476RG template, yet, the STM32CubeMX tool seems to be the best option to get going if you indeed want to stick with the open source tools.

(Sidenote: In any case I think it's worth supporting Carmine with his book. I paid ~10$ and it already saved me quite some time with setting up the IDE and toolchain etc. Disclaimer: I have no connection to the author.)

[legacy]

But it's not an option where I work 'cause we do only free (as in freedom) software, as for ex. if PSoc doesn't work on Linux -> No PSoc

is that fanboys lab? 

[legacy]

I know how the build chain works, the repos, package manager and

and was not the point