8 years, 6 months ago.

Application program simply doesn't start

Hello, I kindly ask for help:

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 (Embedded Artists' LabTool).

I compiled and let run few mbed programs on this hardware, all of them were module test frames. Some test data were sent to the NUCLEO via PA10 and few debug infomation was sent back via PA9. A simple LSA is connected to PA9 and PA10 to watch the serial traffic and to other output pins (PC7, PB6, PA7, PA6, PA5) as debugging aid. The program is about 17.6kB long and uses 2.2kB RAM (plus stack of course). Very simple. All this usually works fine. Normally the program starts immediately after download and "does something" when I run the test data generator on the PC.

Now the program simply doesn't start: It is compiled, downloaded onto my PC and then downloaded to the NUCLEO, but nothing happens - neither immediately when download has finished (I should see it in the LSA output as I set PA7 to 1 at the beginning of main()) nor when I send the test data. It also doesn't start when I hit the reset button. Nothing. All tree LEDs are on: LD1, LD2 and LD3.

Then I accidentially deleted the .bin file from my downloads directory (on the PC!) and was able to start the program, it not only worked, it even worked correctly. So I became accustomed to this ritual: Compile, download to the PC, download to the NUCLEO, delete from the PC, start the test data generator on the PC to feed PA9 and log PA10. Download is performed by dragging and dropping the .bin file from the download directory to the device which is listed as "NUCLEO (J:)" in the left column of the explorer.

Now even this doesn't work any more. The program doesn't start whatever I do. It does not help to recompile and try again, this ugly state is stable. I do not think that I have broken the device: When I compile, download and download another program (just another module's testframe) it starts and works correctly. Reverting to the "ill" program does not help, it remains "ill".

Is this a known behaviour? Is there any problem in the loader? Is there any workaraound? Is there an update which I don't know of? Is there any other solution?

Thank you very much in advance. Sincerely, Helmut

P.S.: I wanted to start a discussion instead of posing a question, but this didn't work.

Question relating to:

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

1 Answer

8 years, 6 months ago.

This is probably a software bug in your code since other programs are still working. Possible cause could be that you use a pin for an illegal function. For example assign a wrong pin to the TX or RX of a serial port, or swap a TX and RX pin. Do some tests by incrementally disabling declarations/instantiations until things start working again. Note that all global instantiations and constructors are executed BEFORE the first line of code in your main is executed. A crash in an instantiation will explain why PA7 is never set.

Yes, I thought on an instantiation of a static object. But I had the following: Compile, download to PC, download to NUCLEO, didn't start; compile (the same code!), download to PC, download to NUCLEO, delete from PC, worked. Thank you and kind regards, Helmut

posted by Helmut Stettmaier 25 Sep 2015

Hmm, you should be able to download straight to the nucleo. Intermediate saving on the PC is not necessary. Cant explain this behaviour. Perhaps your filesystem has caching issues and downloads an old or incomplete version of the bin. I have also sometimes seen my virusscanner complaining and blocking bin file downloads. Do you see any fail messages when downloading to nucleo.

posted by Wim Huiskamp 25 Sep 2015

Downloading directly to NOCLEO (J:) yields the same results, the good case and the bad case. There is one difference:

In the good case (the program that starts) LD2 is dark after loading. in the bad case (the program that doesn't start) LD2 is bright after loading. LD1 and LD3 are always bright.

Caching: The problem also happens when the PC was booted.

There is no error message.

The Windows defender never complained about the .bin files.

I now port the stuff onto another hardware (LPC1768) and look (and will report) what happens - this will take some time.

Thank you for the effort!

Kind regards, Helmut

Ok, The stuff is on the mbed_NXP_LPC1768 and there it starts - the output on pin p28 is not ok and shows me that porting is not trivial, but the program is loaded and it starts.

Kind regards, Helmut

posted by Helmut Stettmaier 25 Sep 2015

LD1 indicates communication by the STlink programmer part. It should be green when communication was successful and orange when there was an error. LD2 is controlled by your software, but it may also be switched on when an error is detected. LD3 should be on, that is the power LED for the target processor.

It seems that programming fails sometimes. Check the USB cable and connections: a long or bad cable may lead to a powerdip during programming and could cause trouble.

posted by Wim Huiskamp 25 Sep 2015