stm32f4-discovery toolchain help - Page 1
Forum section: electronics / general

author: Joshuamcd22
author_rank: Contributor
timestamp: March 08, 2014, 08:34:42 pm
content: 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

author: pablintino
author_rank: Contributor
timestamp: March 08, 2014, 09:31:57 pm
content: 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.htmhttp://www.yagarto.org/

author: andyturk
author_rank: Frequent Contributor
timestamp: March 09, 2014, 12:45:13 am
content: https://launchpad.net/gcc-arm-embedded

author: dannyf
author_rank: Super Contributor
timestamp: March 09, 2014, 12:47:57 am
content: QuoteEasy:1) make a $199 donation to a charity of your choice; and2) download a copy of CoIDE.I would also 2nd the suggestion for the gcc-arm compiler above.

author: Lizerd
author_rank: Contributor
timestamp: March 09, 2014, 07:27:19 am
content: http://www.emblocks.orgbased on Code:Blocks is great

author: luky315
author_rank: Regular Contributor
timestamp: March 09, 2014, 11:58:11 am
content: I have to agree: Em::Blocks is great. Small, fast, direct support for ST-link and the GNU compiler is integrated.

author: dannyf
author_rank: Super Contributor
timestamp: March 09, 2014, 01:43:51 pm
content: 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.

author: blewisjr
author_rank: Frequent Contributor
timestamp: March 09, 2014, 03:09:41 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: March 09, 2014, 03:30:40 pm
content: QuoteIDE 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.

author: blewisjr
author_rank: Frequent Contributor
timestamp: March 09, 2014, 05:29:48 pm
content: Quote from: dannyf on March 09, 2014, 03:30:40 pmIt 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.

author: dannyf
author_rank: Super Contributor
timestamp: March 09, 2014, 06:33:08 pm
content: 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.

author: poorchava
author_rank: Super Contributor
timestamp: March 11, 2014, 07:08:32 am
content: 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)

author: blewisjr
author_rank: Frequent Contributor
timestamp: March 11, 2014, 12:52:00 pm
content: Quote from: poorchava on March 11, 2014, 07:08:32 amI 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.

author: dannyf
author_rank: Super Contributor
timestamp: March 11, 2014, 01:43:29 pm
content: 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.

author: rhdf
author_rank: Contributor
timestamp: August 31, 2015, 10:05:13 pm
content: 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

author: Psi
author_rank: Super Contributor
timestamp: September 01, 2015, 12:29:47 am
content: +1 for emblocksIt 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 imhoIt'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

author: rhdf
author_rank: Contributor
timestamp: September 01, 2015, 01:00:02 am
content: So... the best solution is to install both? (if I want to use the cube libs)

author: Psi
author_rank: Super Contributor
timestamp: September 01, 2015, 09:39:41 am
content: 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.

author: old gregg
author_rank: Regular Contributor
timestamp: September 01, 2015, 09:48:59 pm
content: 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.

author: Muxr
author_rank: Super Contributor
timestamp: September 02, 2015, 07:14:25 am
content: 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.

author: rhdf
author_rank: Contributor
timestamp: September 03, 2015, 11:14:46 pm
content: 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)

author: MT
author_rank: Super Contributor
timestamp: September 07, 2015, 11:02:19 pm
content: 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 useif not you have various degrees of problems. I can gladly recomend EB.

author: Muxr
author_rank: Super Contributor
timestamp: September 08, 2015, 01:44:56 pm
content: Quote from: MT on September 07, 2015, 11:02:19 pmSo 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.

author: Gabri74
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:24:38 pm
content: 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.aspI suggest you to try the old 4.x branch series, because starting with the 5.x series you must download a separateMCU 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 needto complete to obtain the download link. Not sure how long this link will be valid)http://www.keil.com/fid/oj5atuw53j1j1w6sah11bwrwywxd6y2w09yxd1/files/eval/mdk516a.exeIf the above link does not work, use this and fill random info into all the fileds. A valid email is NOT neededhttps://www.keil.com/demo/eval/arm.htmHere you will find the 4.74 version (SUGGESTED):direct link:http://www.keil.com/fid/5g5s5fwlgtwj1w2xe411yd9b0w3ohujmwijw11/files/eval/mdk474.exeIf the above link does not work, use this and fill random info into all the fileds. A valid email is NOT neededhttps://www.keil.com/demo/eval/armv4.htmNote 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 THEMbecause at least a couple of them are known trojans.

author: Gabri74
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:26:46 pm
content: Quote from: Gabri74 on September 08, 2015, 04:24:38 pmI mean a real email. Valid email is needed. This will suffice:https://10minutemail.com/10MinuteMail/index.html

author: Gabri74
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:35:16 pm
content: Regarding the STM32 Cube / old low-level library debate, I've talked with a friend which works in ST and told methey 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 berelease soon.. fingers-crossed ;-)

author: Gabri74
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:40:08 pm
content: See also really good suggestions by newbrain here:https://www.eevblog.com/forum/microcontrollers/best-ide-for-stm32f7-discovery-board/

author: bigdawg
author_rank: Regular Contributor
timestamp: September 08, 2015, 04:50:09 pm
content: Quote from: Gabri74 on September 08, 2015, 04:35:16 pmThis 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

author: Muxr
author_rank: Super Contributor
timestamp: September 08, 2015, 05:10:06 pm
content: Don't get it either. They could have just added some support tohttps://github.com/rogerclarkmelbourne/Arduino_STM32and stuck with libs for professional work. It would have been easier and it would have been a better PR move for the Maker community.

author: MT
author_rank: Super Contributor
timestamp: September 08, 2015, 08:23:07 pm
content: QuoteNot strongly enough!QuoteIt's interesting to note that marketing""have concerns about newbies"somethingthat is completely missing at ST's own forum and pushed that responsability onto a fewindividuals like clive 1 for instance!QuoteIt would have been interessting to know when in time they recieved the complaints becuse as itseams ST have made wrong for years upon years!QuoteWell, that's really some eyebrowe lifting things you relaying to us ST users, so what does thatactually mean? HAL and SPL completely usless for pros and therefore amied at newbies? Andlikewise 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 sorrythumbs out of their sorry arses and manufacture a PLAIN, CLEAN non fragmented without missingdefinitions, register definition file for each and every device they manufacture and leave all the librarywriting 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 managmentbutt's and i will buy him a dinner when done...

author: Gabri74
author_rank: Regular Contributor
timestamp: September 09, 2015, 07:25:58 am
content: Quote from: MT on September 08, 2015, 08:23:07 pmI'll do it for sure

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2015, 08:33:50 am
content: QuoteUm, "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..."

author: Neganur
author_rank: Unknown
timestamp: September 09, 2015, 08:36:23 am
content: Yesterday, I used cube for the first time ever.My experience in how to use it was:Select the targetSelect the tool chain you want to export toSet up the pins and modules you plan to useConfigure themCheck the function block map for red fieldsBuild (or was it generate)Export (tool chain of choice opens with code)Fill in the gaps marked as user code.BuildDownload 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.

author: MT
author_rank: Super Contributor
timestamp: September 09, 2015, 07:38:04 pm
content: Quote from: Muxr on September 08, 2015, 01:44:56 pmSome aproximations simply dont work even when devices is within the same family, just faffing around theproject files is not enough, sometimes a stlinkgdb tweeak is needed, or a change in the scripts, whateverwhich has been the case numerous times before. It all boils down to what ST does and dont do!

author: westfw
author_rank: Super Contributor
timestamp: September 09, 2015, 11:39:39 pm
content: QuoteTo 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.

author: Psi
author_rank: Super Contributor
timestamp: September 10, 2015, 07:47:20 am
content: 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

author: Bassman59
author_rank: Super Contributor
timestamp: September 10, 2015, 04:02:54 pm
content: Quote from: Psi on September 10, 2015, 07:47:20 amIn other words, they (and Atmel, and NXP, and ...) need to do what Silicon Labs does.