Downloaded code does not seem to run.

[xst]

Hello Everyone,

I am running CubeIDE on Windows 10. It installed easily and from the little that I know it runs ok.
I have the official ST-Link interface for OTHER THAN the Nucleo board and I have upgraded the firmware in there to current release.
I have been working on programming an embedded board for 3 weeks now, with only a little bit of success.

=== NUCLEO
I have Nucleo-stm32H743 board.
I wrote a simple blinky-light program.
It compiles (Release) with no errors or warnings.

I download with CubeIDE. CubeIDE says it downloaded ok.
If I press Reset button on Nucleo board, LED does not blink.
If I power down the Nucleo board, then back on, LED does not blink.

I repeated the above download by first connecting Boot0 to 3.3vdc.
Then when programming complete, remove the 3.3vdc jumper. Note on Nucleo board Boot0 is tied low with a pernament 10k ohm resistor.
LED does not blink.

I quit the CubeIDE program and ran CubeProgrammer.
As above, I get the result that the file (.elf) was downloaded ok.
Reset (button) or power down does not cause LED to blink.

I connect a FDTI USB-to-Serial to my computer and the available USART pins on the Nucleo board.
I used CubeProgrammer in Serial mode and downloaded the file (.elf), and it reported download successful.
Reset or power down does not cause the LED to blink.

=== BluePill
I wrote and successfully compiled a (Release) blinky program.
I wired a BluePill to the STLink interface.
Using CubeIDE I programmed BluePill with Boot0 tied High.
CubeIDE reports download was successful.
Then I made Boot0 Low.
Reset (button) or power down does not cause LED to blink.

I quit the CubeIDE program and ran CubeProgrammer.
As above, using the STLink interface, I get the result that the file (.elf) was downloaded ok.
Reset (button) or power down and THE LED NOW BLINKS.

=== Question
Rather than bother everyone with 20 questions about the above failures to run, I will just take a baby step and ask 1 question.
Later I might post another new question.

In the mind-numbing mountain of docs (User Manuals, Reference Manuals, App Notes, etc.) that I have read in the past 3 weeks, I did not find any "instruction" to tie Boot0 High when programming, FOR THE NUCLEO board.
Why?
All other boards, like BluePill, BlackPill, Olimex F407 board, all make it clear that the Boot0 must be High to program and Low to run.

That's my question.

Not sure where to go from here but maybe the answer to my question will help.

Thank you.

XST

[TDK · Accepted solution]

> In the mind-numbing mountain of docs (User Manuals, Reference Manuals, App Notes, etc.) that I have read in the past 3 weeks, I did not find any "instruction" to tie Boot0 High when programming, FOR THE NUCLEO board.
> Why?

Because BOOT0 doesn't need to be high to program. It just needs an SWD connection, which is typically always active unless you're doing something like going to sleep.

It does need to be low to run, which is why it's typically tied low with a resistor or grounded directly.

For the next logical question of "why isn't my code running?": Hard to say, but if you debug the code, you should find out. Perhaps it's stuck waiting for a clock. You can use STM32CubeProgrammer to verify the flash is programmed correctly.

[TDK]

> All other boards, like BluePill, BlackPill, Olimex F407 board, all make it clear that the Boot0 must be High to program and Low to run.

I should have added earlier that the reason these boards require this is because they do not use SWD to connect, but rather a bootloader. Among other things, this makes traditional debugging impossible and drastically reduces productivity. Official ST boards such as the various nucleo boards do not have this limitation as they use the SWD interface.

[Tesla DeLorean]

BOOT0 stops your code from running, which can be helpful if it crashes the MCU early, say powering down the debug pins, or reconfiguring them.

On the H7 it can address LDO / SMPS issues when power cycling.

Typically it's used to start the System Loader, say via USB (DFU loader, reporting as "STM32 BOOT DEVICE") or UART1, allowing for blank devices to be programmed or un-bricked.

Perhaps skim app not AN2606 and AN3155

The trick is perhaps not to read them all, but rather understand where the information is located, so when you need it, or it's salient to your current task, you can find it quickly.

[xst]

Thanks TDK and Tesla,

I use CubeIDE to program and compile with no difficulty, but for downloading and Debugging I have not gotten it to work at all.

I had the Olimex F407 running with a blinky light program but ONLY when programmed from CubeProgrammer.

Olimex F407 does indeed have SWD and that is what I use.

Sadly, I added just a little bit of code to Olimex F407 and now it seems to hang as well.

I have played endlessly with Debug to see if there is some specific place that it is hanging, but not able to get any answers.

I will play with this a bit longer, but maybe its time for me to look elsewhere.

While you folks (TDK and Tesla) seem to be on top of this (congrats to you), I find it disheartening when I read through the many posts on the forum that seem to show that the overall system that ST developed (microcontrollers, development tools, boards, etc) is extremely complicated and has numerous traps and pitfalls. 

Thanks again. I appreciate your attention and insights.

Old man, XST.

[xst]

Hi TDK and Tesla,

I have update. I have code running well on Olimex F407 board.

I think the problem was that I was following the Olimex step-by-step procedure that included changing Boot0 pin.

Since the Olimex board has a SWD connector I was using that for loading code.

But, as TDK pointed out, you don't change Boot0 pin when using SWD. Leave it LOW.

When I did that, the code loaded and instantly started running.

Thank you again.

This is great forum.

Best regards,

XST