cancel
Showing results for 
Search instead for 
Did you mean: 

Nucleo F103RB run on startup

PJW62
Associate II

Hi,

I'm going to say that this is a really nooby question, however I cannot find the answer anywhere.
Background, I'm using a nucleo F103RB, and I've programmed it using CubeIDE. I can connect the board, debug and  run the program fine. The board is powered via Vin at the correct voltages, with JP1 disconnected and JP5 set to E5V.

I need to be able to run this program immediately after the board powers on, without a USB connection. How do I upload a release build of my program to it, because whenever I try using cubeprogrammer, it doesn't run the program after it has restarted. When I've tried dragging and dropping the .elf file in, it's given me a write error.

Thanks in advance for your help,

P

1 ACCEPTED SOLUTION

Accepted Solutions
PJW62
Associate II

I've done some more testing, I need to trigger a reset after power on, best way of doing this is with a POR chip

View solution in original post

18 REPLIES 18
Andrew Neil
Evangelist III

Once your code has been programmed into a microcontroller's Flash, it will always run whenever the microcontroller starts.

After programming with something like CubeProgrammer, you will need to disconnect the programmer, and may need to reset or power-cycle the board.

 


@PJW62 wrote:

When I've tried dragging and dropping the .elf file in, it's given me a write error.


I think you need to use the .bin file?

If externally powering, watch that the STM32 in the ST-LINK is NOT holding the device in reset, you can check the level of the NRST with a scope or meter, you can disconnect it from the Target MCU by way of a Solder Bridge (SB).

Schematics for the boards are under the "CAD Resources" of the product page, download and review.

 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Both the .bin and .elf are the same file, .elf is what cubeIDE defaults to for me. I've checked and the file is loaded onto the flash, however it's still not running when the controller starts. Is there something I need to do to get it to launch from flash?


@PJW62 wrote:

Both the .bin and .elf are the same file


No, they're not: the .bin is a pure binary image of the code in memory; the .elf has a whole lot more "metadata" in it.

I doubt that the ST-Link has the capability to decode a .elf.

https://community.st.com/t5/stm32cubeide-mcus/difference-between-bin-hex-and-elf-file-and-their-sizes/m-p/91681/highlight/true#M2350

 


@PJW62 wrote:

it's still not running when the controller starts. Is there something I need to do to get it to launch from flash?


How do you know it's "not running" ?

As @Tesla DeLorean said, check that the ST-LINK is NOT holding the device in reset.

Add some LEDs to you can see if it's getting stuck in the Hard Fault handler, or some other error handler.

Check any other busy loops - make sure they have an exit timeout

cubeprogrammer takes both .elf and .bin and loads the same data onto the memory. I've just checked the NRST bridge on the ST-Link and it's being held at 3.3 which I assume means that the ST-Link is holding it at reset. Is it as simple as removing that SB?

I know its not running as it should almost immediately cause a relay to click via a transistor. As for getting stuck somewhere would using a release build and having the USB disconnected cause any differences to running it in debug mode where it worked.

Thanks


@PJW62 wrote:

cubeprogrammer takes both .elf and .bin and loads the same data onto the memory.


yes - because CubeProgrammer can interpret both types of files.

When you said, "When I've tried dragging and dropping the .elf file in, it's given me a write error" I though you were talking about dropping the file onto the board's USB MSD - so not using CubeProgrammer ?

 


@PJW62 wrote:

 I've just checked the NRST bridge on the ST-Link and it's being held at 3.3


Have you checked it at the Target processor's NRST pin - in case something else is pulling it low?

 


@PJW62 wrote:

I know its not running as it should


"not running as it should" is not the same as not running at all !

 


@PJW62 wrote:

would using a release build ... cause any differences to running it in debug mode where it worked.


Possibly: often the Release build has a different configuration to a Debug build - in particular, a different optimisation level.

Ok, so it's not NRST as that is still high at the mc, I've also tried the release build with USB plugged in, this for some reason allows the program to run / runs the program. Looking at STLinkUpgrade it says its on STM32 Debug + VCP, would that cause any issues if I tried to run without a usb connection?


@PJW62 wrote:

I've also tried the release build with USB plugged in, this for some reason allows the program to run


Are you sure the microcontroller and any/all additional circuitry you may have is actually getting power and ground without with USB plugged in?

By default, on Nucleo boards, the MCU clock comes from the ST-Link - have you taken that into account?

 


@PJW62 wrote:

its on STM32 Debug + VCP, would that cause any issues if I tried to run without a usb connection?


Not unless your code is waiting for something to arrive via the VCP

 

EDIT: in blue italic.


@Andrew Neil wrote:

By default, on Nucleo boards, the MCU clock comes from the ST-Link - have you taken that into account?



Example:

https://community.st.com/t5/stm32-mcus-boards-and-hardware/nucleo-144-f756zg-stopped-working-after-cut-off-st-link/m-p/687314/highlight/true#M19640