First mbed program

Hi. My name is Martin and I am an mbed virgin.

Or at least I was until this morning. I joined mbed, plugged in my Disco-F429I, generated the default sample program, compiled, downloaded, flashed, and ran. I have a built-in aversion to online tools (I don’t like someone else determining the lifecycle of my toolchain), but that was dang easy.

Technically the Discovery-F429I is not listed as supported, but it shows up in the compiler (as a Discovery-F429ZI - still not sure what the ‘Z’ is for). Worked like a charm, with the only extra step being that I had to use ST-Link to flash the .bin file, because this board does not mount as a filesystem and does not support virtual serial ports, so no printf).

For me, mbed is just a pathway to Llilum, but it was nice to get this far, that easily.

1 Like

Easier to start, especially that you do not need anything to install. The question is, how come you do not have an mbuino? We need to take care of this. :slight_smile:


@ mcalsyn - the naming convention for the STM32F429xxx can be found on page 221 in the datasheet on [url][/url]

Z = For 143, 144 pins (or maybe for Zorro, don’t know for sure)
I = 2048 KB Flash
T = For the LQFP (=Low Profile Quad Flat Package)
6 = Temp range -40 to 85 C
U = For programmed parts, but what the U means I don’t know

At least that’s what my 429er disco is → STM32F429ZIT6U.

In addition, since I’m an addict to VS, I used VisualGDB (80 euros for embedded stuff) to get my blinking experience. And this is within VS, including support for the stepper in debug mode even through the C/CPP code and monitoring the vars/register etc. It’s free for 30 days so you might want to give it a shot even when you need to install it. It supports a lot of MCUs and got great tutorials to get you of the ground, but I reckon mbed will do as well.

To have even NetMf on it go for Justin’s github solution, for getting the LCD on go here [url][/url]

1 Like

Thanks much @ .Peter.

My Disco is a 429I, and the mbed BSP was for the 429ZI, but all seems well. I’ve succeeded in getting various mbed programs (including LCD access) working and had previously played with Justin’s netmf port, which works great, but doesn’t support the LCD.

I tried running some mbed 411RE code on one of my Oxygen 411CE chips and it hangs at startup (with even USB unresponsive, except in BOOT0 mode). I downloaded the mbed source for Keil and played a bit. Without jtag debugging on Oxy, it’s going to be a challenge to sort it out. I suspect that the startup code is hanging while configuring the GPIO pins that the CE doesn’t have or that the Oxygen requires a different clock setup or memory map, but sorting that out will have to wait until next weekend.

I figure if I can get the basic mbed blinky example working (in other words, get the startup code sorted) then I can create an STM32F411CE variation on the exising STM32F411RE BSP and run Llilum on Oxygen. Again, even if I get that working, I am not sure debugging will ever be possible on Oxygen without access to jtag. Am I looking at that wrongly? It seems that all native/mbed debugging for STM is based on jtag-based debugging dongles/boards (as is built into the Disco boards).

@ mcalsyn - Hm, then yr 429er must be different to mine :open_mouth:

And wait, you’ve got llvm & llilum compiled ?

VS didn’t even build a drop folder for me, all kind of weird messages from the start of compiling LLVM 3.8.0 RC1. It’s even worse then the jan 23rd try, at least I’ve had a drop. Barely working but at least something, now nothing, zippo, nada … :wall: :wall:

Well, it might just have been good timing on my part. I created a fork and built from that : [url][/url]
I will be adding my 411CE work there before creating a pull request.
I used Gnu Tools 5.2 2015q4 and llvm source llvm-3.8.0rc1.src and allowed everything to build in ‘debug’ (I have heard that ‘release’ builds do not work). I don’t think I did anything beyond the instructions.

The compile took hours, of course (at least 3 hrs, though I didn’t time it closely). Once LLVM finished, I then built the SDK and the two VSIX’s, and installed them. I need to rebuild the SDK for the STM32F411RE (I left the default LPC chip in place the first time).

I see you got the lcd working with .netmf though, which is cool. Did you do something extra or did Justin add support for that?

1 Like

@ mcalsyn - I might be wrong but with the previous llilum SDK you just need to switch the MCU in code and include the proper front end in the llilum native project, but don’t know f it still the case.

For the 411CE and 411RE, the main diff is the package size with resp. 48/49 vs 64 pins. But they both have 512 Kbytes of flash. The 411CE loses 6 12-bit channels of A/D converters and 14 I/Os

I’ll report my issues with llvm on llilum and see if they’ve got some tips or can tell me where I went wrong :frowning:

When I get back to my lab, I’ll have a look at the 429er project and inform you.

@ .Peter. I’ve also successfully build the SDK last week.
If you happen to have your repository synced with GitHub you’ll find that the instructions on the Wiki regarding the SDK won’t work anymore.
Follow the instructions here and you should get there without any problems:


@ JSimoes - Houston, we’ve got a GO!

But trying on a NucleoF411RE board goes … well not so well …

1>  ARM\Debug\mbed_core.o: In function `SVC_Handler':
1>  C:\Program Files\Microsoft\Llilum\os_layer\ports\mbed/mbed_core.cpp:610: undefined reference to `SVC_Handler_Zelig_VFP_NoFPContext'
1>  ARM\Debug\mbed_core.o: In function `PendSV_Handler':
1>  C:\Program Files\Microsoft\Llilum\os_layer\ports\mbed/mbed_core.cpp:721: undefined reference to `PendSV_Handler_Zelig_VFP'
1>collect2.exe : error : ld returned 1 exit status
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Deploy: 0 succeeded, 0 failed, 0 skipped ==========