Libopencm3 Issue (STM32)

[jnestor481]

Hello everyone,

Completely new to all this. Engineering student who is trying to learn about microcontrollers. Have to confess I'm not the most computer savy person out there. In fact I think they usually turn into a huge time sink of IT issues. So here I am.

I bought a book called Beginning STM32 by Warren Gay. I have followed all the instructions as best I could. I downloaded Cygwin, libopencm3, FreeRTOS (10.2.1), and the ARM cross compiler. I am stuck at this command line prompt that he gives:
line 1: $ cd ~/stm32
line 2: make

At first I couldn't use the 'make' command but I fixed that by reinstalling Cygwin with it included. Then it was an issue with Python, but same fix just reinstalled Cygwin. Now I get the following error message and I'm unsure what to do. I try my best to fix my own problems but hitting my head against a brick wall on this one.

make -C libopencm3 TARGETS=stm32/f1
make[1]: Entering directory '/cygdrive/c/Users/Joe/AppData/Roaming/SPB_Data/stm32/libopencm3'
GENHDR include/libopencm3/stm32/f1/irq.json
/bin/sh: ./scripts/irq2nvic_h: /usr/bin/env: bad interpreter: Permission denied
make[1]: *** [Makefile:61: include/libopencm3/stm32/f1/irq.json.genhdr] Error 126
make[1]: Leaving directory '/cygdrive/c/Users/Joe/AppData/Roaming/SPB_Data/stm32/libopencm3'
make: *** [Makefile:38: libopencm3/lib/libopencm3_stm32f1.a] Error 2

I have tried searching for an older version of libopencm3 like the book suggested but did not have any luck.
Any help would be hugely appreciated. Thank you.

[andersm]

I suspect that the irq2nvic_h Python script is not marked as executable, because you downloaded the libopencm3 sources outside the Cygwin environment.

If you want to use Cygwin, the only way to stay sane is to stay completely within the Cygwin environment, and never try mixing it and "native" Windows. MinGW/MSYS2 provide better interoperability with Windows apps, and there's fully native versions of Python. If you're on a recent version of Windows 10, you could also go the other way and install the Windows Subsystem for Linux.

[amiq]

libopencm3 will not build on cygwin - you'll have to compile in the msys environment.

[grantb5]

I bought this Beginning STM32 book by Warren Gay also and hoped to get the examples going on Windows somehow. I found the CygWin step was the most confounding and gave up there. I don't want to dual boot or use a standalone linux machine. Unless there is a decent tutorial on how to set up CygWin so that it works with the book example, I cannot proceed or recommend this to anyone wanting the same development platform (Windows) as me. I have done embedded and linux dev before, but this is beyond my skills.

So I guess my options for Windows PC development are back to Keil (which is "ok" for now) or try the STMCubeIDE,  I have another book, The STM32F103 ARM Microcontroller & Embedded Systems and it is OK and everything works fine. I had hoped to learn RTOS (FreeRTOS or other common one) as well, but need to find a pathway yet.

[hansd]

I bought the book too and was not able to build the library on Windows. I just ported it to the STM32405-H405 Olimex board. The same can be done for any other board. The libopencm3 library is not complete and not sure if there is any serious development. No error handling implemented! But other than that much faster compared to the HAL engine. I have attached a little test project for STM32CubeIDE.

[KE5FX]

It's unfortunate that people still mess around with Cygwin when all of those tools have perfectly good native arm-none-eabi-xxx versions.  Authors of those books don't do their audiences any favors by dragging in all that cruft.

[newbrain]

It's unfortunate that people still mess around with Cygwin when all of those tools have perfectly good native arm-none-eabi-xxx versions.  Authors of those books don't do their audiences any favors by dragging in all that cruft.

This.

And instead of messing wit cygwin, use WSL.
Running Linux command line based builds has always worked for me.

[krish2487]

Or you know... sping up a linux machine / VM and compile there.. :-D
Still a lot less hair pulling than trying to get this to work on windows. FWIW, I use libopencm3 for my learning with STM32, and I have resorted to keeping things simple, salvaging the core peripherals code from the authors github repo without the freertos stuff thrown in. The additional variables and complexity it(freertos) brings in does not help a beginner trying to learn the framework.

It's unfortunate that people still mess around with Cygwin when all of those tools have perfectly good native arm-none-eabi-xxx versions.  Authors of those books don't do their audiences any favors by dragging in all that cruft.

This.

And instead of messing wit cygwin, use WSL.
Running Linux command line based builds has always worked for me.

[Kjelt]

I just bought an external ssd and installed Ubuntu, works great.

[newbrain]

Or you know... sping up a linux machine / VM and compile there.. :-D

Which, with WSL2, is what is happening, transparently and with better Windows integration than a pure VM.

But with libopencm3 I had no problems whatsoever even in WSL1.
No hair pulling at all (not that I would be able to do a lot of it in any case...).

Of course, going completely Linux is still a good alternative.

[Kjelt]

I can really recommend it.
Use clonezilla to make a clonefile of the drive , only 25GB, put those files on the NAS if anything happens, restore and up and running. I was never a big Linux fan but this is easy peasy, in four years you restore the file and you can rebuild your program. I used ST Cube two years ago, MX and studio have been moved to IDE or something, the libraries per processor are 800MB upto 1.2GB and they change continuously. Still try to experiment with it but I do like the libopencm3 with the arm gcc compiler.

[Doctorandus_P]

I love the book, but haven't touched a Windoze PC for years, know nothing about the Cygwin stuff.

Isn't that microsoft company supposed to have some "sub system for unix" built in these day's, or is that also a part of their FUD?

https://en.wikipedia.org/wiki/Fear,_uncertainty,_and_doubt

They've purposefully botched so many things in the past that I just quit counting, and using it. I suspect that problems with Python or Cygwin have little to do with those programs but are a result of microsofts endless quest of trying to frustrate their competitors and their users.

[cheeseit]

@Doctorandus_P: nice rant but I'm surprised that you forgot to throw in a M$ or two, or the classic embrace extend extinguish. The past is the past but if you researched it open mindedly you'd discover that Microsoft is a different company today.

Technically you're the one spreading FUD but enjoy your (I'm guessing) Linux, perhaps next year will be the year of Linux on the desktop?

[grantb5]

EDIT: Nevermind. WSL only works on Win10. I won't be getting my next PC until the new year. Back to the drawing board.

Thanks all. I will look at WSL ("Windows Subsystem for Linux" I just learned).  Do I need to install a particular linux OS afterward in order to run this book's code? Recommendations? I also want the debugger to work!? I'm not printf-ing my way through life.

Note: I am work-from-home for the time being and don't have room for another PC and need my Windows box available at all times. So, I can Alt-Tab to another "OS" but not dual boot or set up another PC.

(I remember setting up Windows Hyper-V a long time ago, because I needed to run older MS OS toolset, but it was so-so and fortunately that project is done.)

[krish2487]

You dont need a particularly beefy PC to run a lightweight distro. One of the mini PC intel celeron boxes will work just fine for this. And they arent too expensive or a large footprint either. You can just use it to do the development work and use as a lightweight general purpose PC as well. A ubuntu XFCE or a manjaro I3 will work just fine for code compiling. It will not be fastest PC around, but then it doesnt need to be. The difference in compilation time might be a couple of seconds. You can always have a KVM switch to switch between you windows PC and the code compilation box.

Just throwing some ideas around. :-D

EDIT: Nevermind. WSL only works on Win10. I won't be getting my next PC until the new year. Back to the drawing board.

Thanks all. I will look at WSL ("Windows Subsystem for Linux" I just learned).  Do I need to install a particular linux OS afterward in order to run this book's code? Recommendations? I also want the debugger to work!? I'm not printf-ing my way through life.

Note: I am work-from-home for the time being and don't have room for another PC and need my Windows box available at all times. So, I can Alt-Tab to another "OS" but not dual boot or set up another PC.

(I remember setting up Windows Hyper-V a long time ago, because I needed to run older MS OS toolset, but it was so-so and fortunately that project is done.)

[grantb5]

Thanks, I appreciate it. My most recent linux project was for small TinyCore boxes, in the form factor you describe. I did most of the preliminary development on a regular Ubuntu box. That hardware is available, but at the office. I'm really hoping to dive into STM32 on my Win8 laptop here at home, in cramped quarters. I have room for the laptop and an EVB.

So my options look like

• Keil (using either the limited free license or one of the STM full free licenses for F0 L0 G0),
• Rowley Crossworks (which I am intrigued about (GCC)), or
• I guess STMCubeIDE.

I do want to throw an RTOS on top as well. So I just need time to experiment with these.

[janoc]

What about actually following the instructions on the libopencm3 website/Github instead of messing with unsupported configurations, whether Cygwin or WSL?

https://github.com/libopencm3/libopencm3

The original compilation failure came because Cygwin "convinced" the build you have a Linux-like system and the script was looking for /usr/bin/env tool - which you are unlikely to have in Windows.

Moreover, if you don't want to mess with compiling this library yourself (it is not that hard but you need to know you way around the GNU toolchain and how to build things, not just click buttons in an IDE), install it through PlatformIO. There is a pre-built version there.

[grantb5]

Thanks. I'm sure there is a way forward, for this and the future issues that pop up. Recall that the book is titled Beginning STM32 (not Beginning STM32 for Linux), so to have each Windows reader embark on this journey of discovery is a bit unlikely. Maybe someone less Beginner will come along and put a tutorial together to drag all of us unwitting purchasers by the hand. For now I will set the book aside as there are other texts I can use. This is a large topic area with a new microcontroller (for the reader), new tools, new hardware and new rtos, so I'm guessing it will be a while before I come back around.

[janoc]

How old is that book? Even if it came out today, the text would be at least 2 years old due to how long it takes to get things published, which is eternity. The book has a copyright 2018 - so the content is probably 4 years old at least. It also focuses on STM32F103 - which is the oldest STM32 family and has been largely superseded, even though it is still popular with hobbyists thanks to the cheap "Bluepill" boards from China.

Also, if you buy a book that refers to Windows XP, would you be trying to follow it to the letter in Windows 10 and wondering why things don't work?

I understand your frustration but one needs to be reasonable. Cygwin is not a proper Unix/Posix environment even though it makes a pretty solid effort. I am pretty sure the author has mentioned that the instructions in the book apply to Linux and not Windows. I saw him mentioning that "you may want to download Cygwin if you are on Windows because the demos assume Posix" or something to that effect. Which likely means that he didn't really test his examples with it - libopencm3 has never supported Cygwin build, AFAIK (a bit of googling shows problems with Cygwin and OpenCM3 going back to 2015!). That is unfortunate and feel free to complain to the author and leave a matching review on Amazon (or where did you buy the book from).

As a final note - if you are going to develop for ARM, getting at least some familiarity with Linux is a good idea. Both because the toolset is mostly GNU based and it works a lot better in an Unix-like environment and also because Linux is a common OS on the higher end ARM processors. You don't need to reinstall your PC for that, virtual machine with something like Ubuntu is largely sufficient. Raspberry Pi also cost few bucks - and could literally become your development and debugging platform thanks to its accessible GPIO.

[grantb5]

Thanks for the comments. As an aside, I was drawn to the STM32F103 for the reasons you mention, can you recommend a newer replacement? At the moment all I need are the USB device, 3 UARTS and 64K or flash or more. And a pretty low price (I don't need any more horsepower really). This is to replace an SILabs C8051F with 64K of flash and is around $2 in 1K quantities. I don't mind spending a bit more, like ~ $3 (@ 1k). 

Or I start a new thread perhaps.... I did try the ST MCU Selector, but the drop-down boxes don't work on my phone and it was even less functional on my PC.

[janoc]

If you need a USB device then maybe STM32F072 could be an option (not sure how many UARTs it has). That's Cortex M0. Or you could use one of the newer Cortex M4 series chips - e.g. STM32F4xx series. Even STM32F10x could work, just keep in mind that the chips have some known issues, such as the infamous I2C bugs. However, the newer series have had a lot of improvements, including stuff like USB DFU bootloader (F10x has only serial bootloader), etc.

The product selector on their website works but it is a bit of a pain to use - select the MCU family you want and then on the left side activate only the filters you want. Or use Octopart.com and set the filters there - there you can search across all families at once which the ST's site doesn't allow. Or download CubeMX from ST - I believe there is a parametric search/browser in that too.

[Joku]

+1 download CubeMX to use the product selector, it isn't perfect but it's far better than the website.
If you need to install Java JRE, get the 64bit version, 32bit works for most things but CubeMX has a popup whinging about it on startup.

If you don't care about CPU performance than Cortex M3/M4 is generally going to prove to be a bit of a rip off. If this isn't an urgent project then keep in mind that the newish STM32G0x1 line (Cortex-M0+) will supposedly get new models with USB peripheral sometime very soon, supposedly next few months but such timelines shouldn't be relied upon. If you're interested in this, don't get confused with the USB PD peripheral that already exists on some current STM32G0x1 models, that is for power delivery only (usb voltage / power negotiation). It looks like the STM32G0's with USB peripheral are (initially) only going to come with more Flash & RAM than current STM32G0x1's, cost wise the concern is mainly that it will be 144KB RAM, so you can expect them to be more expensive than current STM32G0x1's but at the same time this is the new budget oriented cortex M0+ on 90nm process so there's some reason to be optimistic.

As for your toolchain, I just started on STM32 and went with a Windows solution but I'm not using libopencm3 so I'm not sure what implications that has. My setup includes the following stuff:

- GNU ARM Embedded Toolchain for win32
- Make for Windows
- CoreUtils for Windows
- VS Code
- λ cmder
- STM32CubeMX & Java JRE 64bit

tbh I'm not even sure what benefits I get from λ cmder, I just followed a recommendation that came with no justification

I think the typical way to use this setup is to start a basic skeleton project in STM32CubeMX to get the basic project framework - mainly the startup and makefile.

Personally I've written "my own" makefile and startup code, heavily helped by online references, in order to become more independent. But that was a pretty big step for someone as clueless as I was about startup code and makefiles going into it.

I'm loving this setup btw, easily the best embedded dev setup I've ever had. Takes a bit to get familiar with VS Code, lots of configurability but most of it isn't obvious or GUI based so  need to refer to doco and search internet for "how to" a fair bit when you start out if you're as fussy as I am about optimising your workspace.

One thing I haven't done is setup debug inside VS Code so I can't comment on that. I have a Segger j-link and am using Segger Ozone in the rare occasions that I use that level of debugging, and I'm happy with Ozone so far. Should note that some combination of J-Link / USB driver / VMware / Windows10 managed to get my STM32G071 into a state after a flashing failure that j-link couldn't recover from, possibly because the chip is too new for Segger to have implement better recovery methods (there is a recovery specific app which didn't yet support STM32G0 last I checked). Thankfully had a brand new ST-Link/V2 collecting dust in my cupboard for the last decade or so that worked first go without any fuss and then the J-Link was happy again (the J-link does more things and various things better than ST-Link/V2 so happy to have both).

[janoc]

If you just want to start and not mess with toolchains, build scripts and what not and don't have big money for Keil and such, then PlatformIO is a good choice. They have decent STM32 support, including libOpenCM3, ChibiOS, FreeRTOS, even including the Arduino libraries port if that's what you want. The IDE is based on VS Code (including now free debugger!) but you don't have to use PlatformIO with it.

Otherwise I am using CMake based build system for STM32 which manages all the dependencies, programming and all the idiosyncracies (there is a set of pre-made CMake scripts for this on Github if you want to try it), but then I am also doing software dev. professionally and I know the ins and outs of that tooling. Probably not the best choice for a beginner - if y ou are only starting out with ARM  you would be overwhelmed pretty quickly.

[grantb5]

Wow thanks guys, lots to chew on here.

If you don't care about CPU performance than Cortex M3/M4 is generally going to prove to be a bit of a rip off.

I don't know what that means. I need at least 48Mhz, but more would be "nice".  No FP needed.  I want an inexpensive micro. Say, $3 USD at 1k quantities (just for price comparison). I don't really know what the difference is between those cores.

I installed STM32CubeMX & Java JRE 64bit and had already installed GNU ARM Embedded Toolchain for win32. I had the STM32CubeIDE installed already too, but didn't realize it was a different tool altogether. I'm assuming I have multiple installs of gcc now as a result. No matter.

I used the MX Cross-Selector (was just poking around) and looked for an STM32 replacement for my current C8051F380-GQ-QFP48, which is a single-cycle 48MHz 8051 that is surprisingly fast. In playing around with the STM32F103 I had to get creative to get the F103 to match the C8051F380's bit-banging abilities. Anyway the STM32 outshines the C8051F380 is almost all other ways. Anyway, the cross-selector gives me 500 possible replacements.    Among the top hits were the STM32F070 and 072. Overall I don't get why those are better than the F103 (thanks janoc for some pointers there though). Newer I can see, but...

One thing of note, I believe the Keil tools are free for the STM32F0 G0 and L0 parts. Not just a 32k limited eval. I was using the Keil uVision compiler/IDE for 8051 work so this would be an "easy" move tool-wise. The editor is horrible, but the compiler itself is good.

I will still look into other tools (I've used VSCode before, but I'm not a huge fan of PlatformIO, but just because of how it's constantly updating).

[janoc]

Just use the official ARM GCC toolchain with whichever IDE you prefer - no need to deal with the crippled Keil crap. The basic tooling for ARM is completely open source, you only pay for conveniences (e.g. Segger J-Link) that are nice to have but not necessary.

Anyway, the cross-selector gives me 500 possible replacements.    Among the top hits were the STM32F070 and 072. Overall I don't get why those are better than the F103 (thanks janoc for some pointers there though). Newer I can see, but...

Cheaper, newer, easier to use peripherals. However, slower/simpler core (Cortex M0 vs Cortex M3) and usually less memory - which could be an issue if you want to do anything complex with USB.

I will still look into other tools (I've used VSCode before, but I'm not a huge fan of PlatformIO, but just because of how it's constantly updating).

You don't need to update it. It is in active development and support, that's why there are updates but they aren't mandatory, you know.