I did that as well heh, so some degree. I just used JLink and connect under reset. Since the pins only set themselves to input when the code boots, you can connect the debugger to the core right after reset. Debugger and their tools saved me that time :)

couldn't you boot0 yourself to safety?

All methods using STLINK or JLink utilities are available for the devboards using onboard debugger. With JLink you are limited to debuggers up to version 2.1. It does not work with newer stlink v3.

That's correct. In the video I used a ft232 chip on a breadboard which has dtr(connected to boot0) and rst available. Some uart cables/adapters omit dtr pin, like the official ftdi cables, that just have cts instead of dtr. Cta cannot be used as output, so for flashing it's useless. Well, you can also get the device into boot mode by switching pins manualy and therefore you can omit options that use that pin.

@ Thanks! So basically you are taking advantage of the fact that the dtr lines goes high right before starting transmitting the new firmware and goes low when finished, which is exactly how you want the boot0 pin to behave, so you just tie them together, is this correct?

Partly. In the video I configure the particular ftdi chip to have the dtr low at idle - this would make the stm32 use default boot from flash. Then I toggle the dtr line along with rts using the stm32flash command, which puts the mcu into bootloader mode and out again after flashing. So if your ftdi/serial cable does not have dtr, then remove the ping toggling options of dtr and rts and perform the bootloader yourself and also the device reset after flashing as well. That reminds me to look into cables with dtr exposed instead of cts.

@ Ok now after reading the stm32flash docs it's more clear what you are doing. I will not use an ftdi chip in my design so I will have to possibly place an inverter gate in dtr and rts, will check the datasheet for the default logic level. One last thing I need to verify is that stm32flash is able to use those signals regardless of the uart ic in use. Seems pretty obvious that this pin toggling action should work with any uart ic that has those signal. Personally I will use the CH340C.

I didn't end up using the dtr pin, i just set boot0 = 1 and boot1 = 0, and use the stm32flash utility and it worked (nucleo-F401RE), this is the command : stm32flash.exe -w led_blinking_F4.elf -v -g 0x0 -b 9600 COM10

Hi, I'm glad that my videos have helped you. When you flash your board, more often than not, you flash your program in .bin format, which includes everything (functions, static data, constants, system init, etc.), you write it into internal flash memory which is non-volatile. This means, that even after disconnecting power, the contents of your application will be left intact. Therefore you can flash your board with either Cubeprogrammer or with newer stlink v2s you can just drag and drop the binary into the mounted stlink drive and the device will flash itself. After that on every power on , the board will start your application. Thank you for watching.

@ I took your advice and it worked! Then, I powered by an external ps and it powered-up and ran my code. Then, I powered down and reconnected to ST-LINK and could continue development. Wonderful, thanks again!

Thank you for the comment, I'm glad you found my video usefull. As for the terminal prompt ... I was in the process of building a better one (as you can see in all the videos, even ditros change). Only constant is zsh, which is my shell of choice. I played around the raw .zshrc config adding info to the right part of the promt. Here I moved usual username and hostname to the right with grey colors, so that there is more space for the current path. Later I moved the username:hostname back to the left with rainbow colors, but I added git info (when in git repository) to the right. I don't have that exact config anymore, but I configured this with snippets from the forums (search for "zsh right prompt") and you'll figure out the syntax and where to change the contents and color. I recommend Luke Smith's channel and his config: github.com/LukeSmithxyz/voidrice/blob/master/.config/zsh/.zshrc Nowdays I use starship.rs/ and I love the two line promt - now there is SPACE for the command line even with a long directory path. I even added git info, nix, etc. You can find it in my repository for fedora config (distro does not matter): github.com/prtzl/fedora-config.

@ thanks for the detailed response! I'll definitely search that I also use Zsh (spaceship-prompt), I've been looking at upgrading to starship but haven't made the switch yet. I've also been watching the warp terminal project

I cannot find a problem just by your description. Your mcu should have id of 0x466 and is supposed to be supported on stlink. Can you try st-probe to get some info? Also, do you have all the libraries? Did the build succeed with no major warnings or errors? Have you installed all the correct libraries? Also, do you have the correct image for your mcu? Did it build correctly? There is a possibility that either the mcu is dead or the programmer is not working 100%. I have one dead f4 discovery board. I tried using stlink (original), then the open source tool, I also tried reflashing the debugging with jlink and using external debugger to confirm that none of them worked. If you have that option, you can try (using windows) to convert a debugger to jlink and try with that as well. Also you can try using stlink (open source) to erase the whole memory and try flashing again - create new dummy project that you know should work for this mcu.

I'm not sure, but you can check built in dfu bootloader specification datasheet and find your mcu family. It will have at least uart but some also have usb and i2c, maybe spi as well.

I can't belive I did not mentioned this, because I have a feeling I did in at least one video, but I cannot find it. I have also tested this now as well, but the answer is still NO. It will update certain sections, where you add new peripherals and it would add include paths, but if you delete some parts of it, it won't write them back or correct them. Only if you delete the makefile, it will create a new one. Make sure to use git for your project, even if just localy, to prevent any accidental damage to the makefile.

@ ok, thank you. I just thought that put flash tasks to make file is wrong (ideologically) vscode can cascade tasks. For example you can create task make, flash and combine them into another build'n'flash. And use it in preLaunch. In this case you can leave makefile prestine.

You can do it as shown in the video for the stlink/jlink that you have, or uart. Just insert the path to the binary file into your download command.

Can you share that .bin file?

You can run make or build with ide.

I also use Cube for work. Other companies have their versions like Cypress Psoc creator so it's common to use such tools. If nothing more you save time for initialization and also removes possibility for such bugs.

Thank you for kind words. I'm glad you find my videos useful. I'm using zsh with starship on my system. This is what gives me a two line prompr with current directory, git info and more. Vscode uses your default shell, so when I launch a terminal in vscode, it runs zsh, which is configured with starship and other addons. Search on internet for starship.rs . It also works with bash and fish and is easy to configure. Cheers!

Oh, you can also find my starship and zsh config (the colors and git info) im my github repository github.com/prtzl/fedora-config inside dotfiles directory (starship.toml and zsh.rc)

@ Thank you! I will try to configure it. Also, I would like to work with FFT. Do you know how can I use CMSIS library to calculate FFT with DSP of STM32F446ze?. Thank you very much again!

Moze. A raje po anglesko da je za sve.

@ Hvala Matej ali problem je rijesen.Veliko hvala da ste pokazali spremnost da pomognete.

Try set CPUTAPID 0 in your .cfg