Affordable and flexible platform to ease prototyping using a STM32L053R8T6 microcontroller.

Why doesn't NUCLEO L053R8 start my program?

28 Sep 2015


Ok, I had posted a question on this theme but it seems to be a bigger item, so I continue here. Perhaps you may want to read this question before: but I try to keep this thread stand allone.

Components: NUCLEO-L053R8 (Version: 0200 Build: Aug 27 2014 13:29:28 out of its mbed.htm), Win8.1, an FTDI-USB/serial converter using 3V3 and a simple LSA (an affordable Embedded Artists' LabTool).

I have observed the following behaviour which I regard as a misbehaviour:

Program loaded, but obviously doesnt start

The program was downloaded dirctly into the NUCLEO but it did not start, neither immediately after download nor after resetting the NUCLEO. To show this I added a screenshot "NUCLEO-problem(1)" which shows the mbed page and a part of the LSA's window. Note that the '>' button of the LSA is grey as I had clicked it to enable the LSA, but nothing came in.

This is of course not a proof that the program didn't run, but see the following steps.

Recompile and download again

I recompiled the same program just to trigger another download. As to be expected nothing happens until the download is started - see the download dialog and the unaltered state of the LSA in the screenshot "NUCLEO-problem(2)". I chose "Save file" ("Datei speichern") and hit "OK".

The program starts

See "NUCLEO-problem(3)" to discover, that before downloading, when still the "old" program is stored in the NUCLEO, it "suddenly" starts, as you can see in the LSA window.

The newly downloaded program doesn't start

Now I click "Store" ("Speichern"), LD1 blinks red&green, gets ready and the newly loaded program doesn't start.

A tiny closer look

When the program started finally it executed 2 constructors of static objects:


    baud (115200);
    attach (getHFM4Byte);

As can be seen the green debug line is set to high, this was also the trigger condition for the LSA and the success is visible (the rising edge hides under the red trigger line). Also to be seen is that the brown signal is already high, this is done in the base class constructor, the brown signal is Serial1_TX. All this looks quite ok.

cMLinkDriver TD_Driver;

cMLinkDriver::cMLinkDriver(): cInputDriver() {
    /* ... */

Afterwards the constructor of the high level driver is started and, as can be seen with the 1st blue pulse it ran and finished.

Everything what happens afterwards is not necessarily correct (It's work in progress) but can be explained. This lets me assume that the program ran as is to expected regarding the source code. It just took a weird action to start it.

Speculating what could have happened

Did the query of the virtual memory stick "NUCLEO", which was performed for the download dialog, trigger something in the NUCLEO to start the program finally? I tried it out and simply clicking on "NUCLEO (J:)" in the left column of the explorer and it also helped.

Formerly the bevaviour was even more weird: I downloaded the program into my downloads directory (default), copied it into the NUCLEO from there and, in order to get it started, I deleted the binary from the downloads directory (!) - did the deletion of the binary cause the explorer to check if the copying was complete and therefore "ask" the NUCLEO something and trigger the start of the program?

I have written several programs for the NUCLEO and they all worked fine (finally:-), especially they started immediately as expected. I have no idea why only this one program causes difficulties. The flash sizes of the programs were somehow comparable, currently about 17 kB.

Wim Huiskamp kindly investigated my problem (see the question linked above), and I want to say a sincere Thank you - but I am afraid he did not find the correct answer.

The problem is still open...

Kind regards, Helmut

P.S.: I did not find a way to upload the screenshots, the forum doesn't love me... I finally managed to start a discussion thread (using a tricky trick), but I can't upload pictures. You will find the screenshots in the following directory: and up to ...(4).png. Sorry for the inconvenience.