stm32f4-discovery toolchain help

[Joshuamcd22]

Hi,

I've had an stm32f4-discovery board laying around, for a while, and have decided that I want to use it in my next project (a flight controller for my tricopter) but, I am having some trouble getting a toolchain setup, anything free that I have found, is next to impossible to get setup, or has "try before you buy" code size limits. 

As I potentially want to be able to sell my project, I don't want to buy a $200 personal licence, and have to buy a $2000 commercial licence later.  I want to get something for at most $200 (free would be better) that will allow me to (legally) sell a product developed with it.

Any recomendations would be GREAT!

Thanks,
Josh

[pablintino]

Hi, have you checked Coide?. It's free and it works quite good (eclipse based). You only need to install the Coide package and an external compiler (in the past i had tried it with yagarto gcc).
Here are some links:
http://www.coocox.org/coocox_coide.htm
http://www.yagarto.org/

[andyturk]

https://launchpad.net/gcc-arm-embedded

[dannyf]

I don't want to buy a $200 personal licence,

Easy:

1) make a $199 donation to a charity of your choice; and
2) download a copy of CoIDE.

I would also 2nd the suggestion for the gcc-arm compiler above.

[Lizerd]

http://www.emblocks.org based on Code:Blocks is great

[luky315]

I have to agree: Em::Blocks is great. Small, fast, direct support for ST-link and the GNU compiler is integrated.

[dannyf]

I would 2nd that recommendation for emblocks: it has been my exclusive platform for anything pic24 - I have been an advocate since its beta days. It is an absolute joy to use and infinitely better than anything Microchip has produced.

[blewisjr]

I don't know about emblocks.  I have been having massive issues with CoIDE.  Something about there servers being totally borked and other crap.  So I decided to try emblocks and the IDE portion seems great but for some reason the code it builds will not run on my STM32F3Discovery.  For some unknown reason I just could not get it to work.  The code is valid code as it is only a slightly modified ST Example to blink a led and the code worked with CoIDE.  Now sadly I have no IDE to use at all because I can't re download CoIDE as there servers are torched.

[dannyf]

The code is valid code

IDE is dumb in that it cannot read your mind and you have to set up a project in the IDE so it compiles as expected. Part of the job there is to read the IDE manual and understand how it works so you can make it work for you / your projects.

That's where CoIDE excels - their project wizard is top notch.

[blewisjr]

The code is valid code

IDE is dumb in that it cannot read your mind and you have to set up a project in the IDE so it compiles as expected. Part of the job there is to read the IDE manual and understand how it works so you can make it work for you / your projects.

That's where CoIDE excels - their project wizard is top notch.

It seems like it is a problem with their generated startup code etc...  For some reason their code is throwing a Hard Fault.  For now I personally set up a temporary raw eclipse with the arm plugin which worked great.  Not sure how to get debugging working yet tho.

[dannyf]

Blaming the chip or the IDE is easy and tempting. But it doesn't help you solve the problem - it only prolongs it. Read the manual(s) and learn the right way of doing things for your tools.

[poorchava]

One more for CoIDE. I've tried building toolchain from scratch and it kinda worked, but it's very touchy and unstable. CoIDE just works. And it supports a very wide range of STM32 family mcus (definitely not the case with NXP's and Atmel's chips)

[blewisjr]

One more for CoIDE. I've tried building toolchain from scratch and it kinda worked, but it's very touchy and unstable. CoIDE just works. And it supports a very wide range of STM32 family mcus (definitely not the case with NXP's and Atmel's chips)

I do agree building the toolchain from scratch at least on windows is not the way to go.  It is actually kind of interesting when you look into it and realize the ARM linux support is actually a lot better then most people think because most of the tools you need to use to build a toolchain from scratch on windows are all linux tools which never seems to work out quite right with all sorts of weird quirky bugs.  CoIDE does just work where other open options have been hit and miss for me at least.  Even with this in mind I am in the process of working out the details of setting up a toolchain in Linux as that is where I am most comfortable.  Everyone has there own preferences I guess.

As for the OP if running windows listen and go for CoIDE it is the best cheap tool you will find period for embedded development on windows with STM chips at least.  If using NXP your best option is probably the LPCExpresso tool which has quite a hefty code size limit not at like 256k I think.

[dannyf]

LPCxpresso is a lot clunker (if that's even a word) than CoIDE os emblocks. I would avoid it at all cost: the only time I use it is to flash the LPCxpresso boards for programs developed from keil or iar.

On Lpcxpresso: I have this particular LPCXpresso board that I got from going to a seminar in China. It could not be programmed by the standard lpc-link that comes with lpcxpresso and requires a peculiar piece of driver from a firm that appears to also manufacture (and design?) st-link. That driver also works for IAR but not Keil. Very weird.

[rhdf]

Whats the latest view on CoIDE vs Em::Blocks?
Or maybe go with "normal" Eclipse + yagarto?

"Simple" to use and compatible with STlink would be nice

[Psi]

+1 for emblocks

It works with discovery boards without issue.
Just select the  board you have and start coding.

Be aware it a bit tricky if you want to use stm32cube app.
Emblocks uses the older standard peripheral library by default.
Fastest way to get cube code compiling in emblocks is to load into coocox and import that project into emblocks. (You can do it direct but its tricky)

Not that it matter stm32cube is horrible it uses up like 32kB of you flash space loading all its library's and structures.

The old standard peripheral library is better imho

It's a pity too because they could have made stm32cube awesome if it had been able to generate all the raw bitlevel register commands with comments instead of a sea of  library calls

[rhdf]

So... the best solution is to install both ? (if I want to use the cube libs)

[Psi]

If your knowledgeable in C and dev environments you could get cube code working in emblocks easy.
I just couldn't figure it out myself, there was some path or setting wrong somewhere.

Getting stm32cube working in coocox was simpler and emblocks can import coocox project files.
So it was a simple way to get it working with all the correct settings.

[old gregg]

CoIDE is pretty easy to use and install. I got something to work on the board in 1/2 hour. Although it seems to crash easily. In 4 for days, I had to terminate the program quite often.

Also, I'm having trouble to add external libraries. I want to try the ST electronics drivers with examples but no success so far.

Something to do with .a file or something. very annoying.

[Muxr]

I tried both CoIDE and em:blocks. CoIDE was slightly easier to setup, but em:blocks wasn't hard per se either. There are good articles on em:blocks online for everything I searched for in order to get going.

em:blocks IDE and feature seem more complete, also I got occasional weird errors and crashes with CoIDE. I think I am going to stick to em:blocks as it appears more mature and feature rich.

[rhdf]

1: Do I really need Cube?
2: I noticed that the "component repo" in CoIde seems to be remarkably "empty" (and the forum is littered with spam-posts)

[MT]

No you dont need Cube, you dont want to need cube , i use it only for pin mapping then take screen dumps using these for references during development. One issue with emblocks/embitz, cooide etc is if they support the part you selected to use
if not you have various degrees of problems. I can gladly recomend EB.

[Muxr]

No you dont need Cube, you dont want to need cube , i use it only for pin mapping then take screen dumps using these for references during development. One issue with emblocks/embitz, cooide etc is if they support the part you selected to use
if not you have various degrees of problems. I can gladly recomend EB.

So far even when the particular model isn't supported you can usually get away with the approximate. They have a major version for each line from what I can tell. For instance I am using a F070 chip currently, but the closest they have is support for F071. So I've been using the setup for F071, since 071 has more features than the 070 I am using I just have to be careful not to use registers that aren't supported on 070. Haven't ran into any issues yet, but I could go in and manually modify all the project files to match if need be.

[Gabri74]

It is proprietary, but I guess Keil uVision/mdk-karm is the fastest way to setup a project for a stm32 dev board.
The downloadable version is free to use but has some code size limitations, see: http://www.keil.com/demo/limits.asp
I suggest you to try the old 4.x branch series, because starting with the 5.x series you must download a separate
MCU support library for every MCU family and is a bit confusing for new users.

Here you can find the 5.16 version (I've already filled and bypassed the personal-info-sourvey you need
to complete to obtain the download link. Not sure how long this link will be valid)
http://www.keil.com/fid/oj5atuw53j1j1w6sah11bwrwywxd6y2w09yxd1/files/eval/mdk516a.exe
If the above link does not work, use this and fill random info into all the fileds. A valid email is NOT needed
https://www.keil.com/demo/eval/arm.htm

Here you will find the 4.74 version (SUGGESTED):
direct link:  http://www.keil.com/fid/5g5s5fwlgtwj1w2xe411yd9b0w3ohujmwijw11/files/eval/mdk474.exe
If the above link does not work, use this and fill random info into all the fileds. A valid email is NOT needed
https://www.keil.com/demo/eval/armv4.htm

Note that uVision4.74 will also work fine in Linux under wine. Versione 5.16 has some issues with MCU packages installer.

NB: if you look around, you will find some keygen to generate a valid full license: PLEASE DO NOT USE THEM
because at least a couple of them are known trojans.

[Gabri74]

If the above link does not work, use this and fill random info into all the fileds. A valid email is NOT needed

I mean a real email. Valid email is needed. This will suffice: https://10minutemail.com/10MinuteMail/index.html

[Gabri74]

Regarding the STM32 Cube / old low-level library debate, I've talked with a friend which works in ST and told me
they hate it as strong as is possible.
It was needed to compete in the arduino/newbies market and was basically forced down their throats my marketing.
The received a lot of complaints from professional developers and company about it being bloated, slow and awful.
Being used to the old fast and bare-metal library I can't stand it. Several K lines of code to get a timer running.. WTF !?!?

But....

he said to me that a new low-level library for experienced developers is being developed and it will be
release soon.. fingers-crossed ;-)

[Gabri74]

See also really good suggestions by newbrain here:
https://www.eevblog.com/forum/microcontrollers/best-ide-for-stm32f7-discovery-board/

[bigdawg]

Regarding the STM32 Cube / old low-level library debate, I've talked with a friend which works in ST and told me
they hate it as strong as is possible.
It was needed to compete in the arduino/newbies market and was basically forced down their throats my marketing.
The received a lot of complaints from professional developers and company about it being bloated, slow and awful.
Being used to the old fast and bare-metal library I can't stand it. Several K lines of code to get a timer running.. WTF !?!?

But....

he said to me that a new low-level library for experienced developers is being developed and it will be
release soon.. fingers-crossed ;-)

This is so weird though because as a "newbie", I think their STMcube implementation is atrocious to say the least. I am not really a fanboy for atmel/TI/NXP but I have worked with boards from each of those companies and trust me, all three of them had better implementation software-wise than STM. If novices like me dont like ST libraries, the pros here dont seem to like it too, than who the heck likes it 

[Muxr]

Don't get it either. They could have just added some support to https://github.com/rogerclarkmelbourne/Arduino_STM32 and stuck with libs for professional work. It would have been easier and it would have been a better PR move for the Maker community.

[MT]

Gabri74 link=topic=27880.msg749871#msg749871 date=1441730116]
Regarding the STM32 Cube / old low-level library debate, I've talked with a friend
which works in ST and told me they hate it as strong as is possible.

Not strongly enough!

It was needed to compete in the arduino/newbies market and was basically
forced down their throats my marketing.

It's interesting to note that marketing ""have concerns about newbies" something
that is completely missing at ST's own forum and pushed that responsability onto a few
individuals like clive 1 for instance!

The received a lot of complaints from professional developers and company about it being bloated,
slow and awful. Being used to the old fast and bare-metal library I can't stand it. Several K lines
of code to get a timer running.. WTF !?!?

It would have been interessting to know when in time they recieved the complaints becuse as it
seams ST have made wrong for years upon years!

But....
he said to me that a new low-level library for experienced developers is
being developed and it will be release soon.. fingers-crossed ;-)

Well, that's really some eyebrowe lifting things you relaying to us ST users, so what does that
actually mean? HAL and SPL completely usless for pros and therefore amied at newbies? And
likewise direct register programming for pros only?

Im a dinosaur but i dont want yet another fucked up abstraction library, i want ST to take their sorry
thumbs out of their sorry arses and manufacture a PLAIN, CLEAN non fragmented without missing
definitions, register definition file for each and every device they manufacture and leave all the library
writing to the users! I want ST to STOP bullying people into the mentality of their MINDS!

Tell your friend at ST that i have a standing order for him to go upstairs and kick the managment
butt's and i will buy him a dinner when done...

[Gabri74]

Tell your friend at ST that i have a standing order for him to go upstairs and kick the managment
butt's and i will buy him a dinner when done...

I'll do it for sure       

[westfw]

They could have just added some support to https://github.com/rogerclarkmelbourne/Arduino_STM32

Um, "Arduino STM32" is quite new (about a year people first started noticing the cheap "Maple" clones, and looked at updating the abandoned Maple code, and maybe sixs months worth of "complete and usable".)  This means it wasn't around at all when CUBE was first being developed.

I hadn't noticed that Cube looked "beginner friendly"; it has many of the same failings as ST's previous (and also "pretty awful") "Standard Peripheral Library."  (IIRC, the original Maple project tried to put Arduino compatibility on top of the ST SPL, and ended up having to give up and start from scratch.)  (alas, other vendors' similar products (Atmel ASF) are similarly awful in similar ways.  And it does look like a poor implementation of a bad set of requirements, but I don't think "as easy to use as Arduino" was among those requirements.  I'm betting "mumble MISRA.  Mumble No Preprocessor complexity.  Mumble C99, no proprietary compiler extensions, no viral libraries.  mumble any known starting state.  works across entire product line from 4k CM0+ to 2MB CM7.)

"Marketing made us and we hate it too" is a lousy excuse.  Please give me "we're trying as hard as we can, and we think we came up with a pretty good solution, and here's why it's good..."

[Neganur]

Yesterday, I used cube for the first time ever.

My experience in how to use it was:
Select the target
Select the tool chain you want to export to
Set up the pins and modules you plan to use
Configure them
Check the function block map for red fields
Build (or was it generate)
Export (tool chain of choice opens with code)
Fill in the gaps marked as user code.
Build
Download into the target.

I had the feeling this was pretty OK, but I had someone who was instructing me. It probably takes a while to learn how to use the tool.

What I liked very much was the way the tool offers an overview/parametric selection of your target down to the very tiniest feature. This is incredibly helpful for HW design tasks where you have to look for e.g. an ST Cortex 4 with CAN and low power. Plug in the check marks and you get a list of targets to choose from.

The reason why I'd like to recommend trying cube just to try the selection feature is that the alternative really sucks. Parametric search on digikey and copy paste features into a spreadsheet to compare and select something took me a lot longer.

[MT]

No you dont need Cube, you dont want to need cube , i use it only for pin mapping then take screen dumps using these for references during development. One issue with emblocks/embitz, cooide etc is if they support the part you selected to use
if not you have various degrees of problems. I can gladly recomend EB.

So far even when the particular model isn't supported you can usually get away with the approximate. They have a major version for each line from what I can tell. For instance I am using a F070 chip currently, but the closest they have is support for F071. So I've been using the setup for F071, since 071 has more features than the 070 I am using I just have to be careful not to use registers that aren't supported on 070. Haven't ran into any issues yet, but I could go in and manually modify all the project files to match if need be.

Some aproximations simply dont work even when devices is within the same family, just faffing around the
project files is not enough, sometimes a stlinkgdb tweeak is needed, or a change in the scripts, whatever
which has been the case numerous times before. It all boils down to what ST does and dont do!

[westfw]

other vendors' similar products are similarly awful in similar ways.

To be fair, it is REALLY DIFFICULT to maintain "simple" access to a very large feature set.  With something like Arduino, you get a nice but extremely simplified API that implements a very small subset of the features of whichever processor you happen to be using.  With something like Cube or ASF, you want to expose all of the features of the chip, and you've pretty much pissed off most of your potential users by the time you implement an abstracted data structure that has room for all of the features of a peripheral.  (pinMode(INPUT|OUTPUT) is swell.  pinMode(direction, pullup, pulldown, input buffer enable, drive strength, ...) - not so swell.  Yes, configuring the pins in a GUI is nice, but having the resulting code call the fully general init function is pretty frustrating.

[Psi]

The idea behind cube is awesome.
An app you can use to graphically set all the features/pinouts you want with lots of explanations about how they work.

But it needs to generate discrete blocks the user can cut paste into their code and it needs to be very close to bit level. I don't mind a little standard library stuff, but only a little. I need to be able to see what it's doing

[Bassman59]

The idea behind cube is awesome.
An app you can use to graphically set all the features/pinouts you want with lots of explanations about how they work.

But it needs to generate discrete blocks the user can cut paste into their code and it needs to be very close to bit level. I don't mind a little standard library stuff, but only a little. I need to be able to see what it's doing

In other words, they (and Atmel, and NXP, and ...) need to do what Silicon Labs does.