You're welcome! Thanks for the feedback.

You're welcome.

I appreciate that!

@@0033mer I have an idea for a video after watching this one for 6 times. lol What do you think about using this black pill board hooked to an RN487x serial bluetooth module to perform OTA firmware updates using flash loader method (USART1 on pins A9 & A10)? In order to also be able to remotely make the device go into bootloader mode without any human interaction on buttons BOOT0 & NRST, you could replace the buttons or add a transistor or a load switch controlled by the GPIOs present on the bluetooth module. You could control the status of both buttons remotely by means of AT commands and independently from the microcontroller. Something similar has been made for arduino. However, the HM-10 consumes relatively high current when it goes into "sleep" github.com/MEming/Device-Firmware-Update-OTA-Bluetooth-Low-Energy What do you think?

To simplify OTA programming on any microcontroller I use Forth as my programming language. The Forth operating system enables you not only to upgrade code but to also upgrade the compiler as the code is running. NASA has used this technique for OTA programming on their space probes millions of miles away. www.forth.com/resources/space-applications/ Check out my video where I use this technique on the Arduino Nano. kzfaq.info/get/bejne/rLNzkq9-0tqqkZc.html To increase range you can use LoRa instead of Bluetooth. kzfaq.info/get/bejne/jJidotOr086pfHk.html

@@0033mer Cool forth video! I haven't used it so far. I am using Micropython, and by following the approach that I proposed above, I would be able to just update the internal ".py" files or update the whole interpreter remotely. My application in particular is already using a lora module to interace with a LoRaWAN network, I thought a BLE module would bring OTA promaming, as well as Debugging through the terminal. Additionally, I think it worth mentioning that the node will physically located up on a mast that is part of the power distribution network.

Glad it helped

Yes .. that is a nice feature. I am running Micropython on a Discovery board STM32F407. kzfaq.info/get/bejne/l8V3Zrqiz8y0cnU.html

You're welcome.

You're welcome!

You are welcome!

You're welcome!

10uf cap on the 3.3v line for a bit of filtering.

100mhz.fs was written for the STM Nucleo board where the HSE clock is 8 Mhz. Blackpill has a 25 MHz HSE clock. To program the PLL divider properly change the line of code: 8 0 lshift or ---> 25 0 lshift or

@@0033mer Woohoo! That worked - thanks!

The external memory is SPI flash and is used like any SPI device. Check the schematic for the pins that are used for the SPI port and the data sheet for programming. www.adafruit.com/product/4763

@@0033mer thanks a lot dear !!!!!

If you are not using the USB port you can set pins PA11/12 as UART6. UART6 is also on pins PC6/7 but is not brought out on the module. If you go to the Nucleo F11RE board you can access UART6.

@@0033mer Thanks for the very useful info and informed response. I really appreciate it. I bought myself a Nucleo-401 demo board as well as BlackPill to play with so I should be good to go. Installing the USB bootloader was a great idea because it gets you away from the boot pin manipulation. I prefer to build projects where the user just plugs in the USB and can invoke the bootloader with a simple power reset. Super useful. Using STLink via SWD port wipes out the user bootloader but it doesn't matter during code dev anyway, just reinstall the BL at the end and BL in the finished app. I've been doing that with PIC devices forever so the workflow is the same in that respect. I want to design STM32F411RE (64-tqfp) onto my own custom PCBs but I can't seem to buy the raw chips anywhere (global shortage?) so instead I'm buying the cheap devboards to get by. A nice advantage of the very common serial bootloaders going through an FTDI USB-to-UART converter is that you can route the FTDI /DTR pin to drive the MCU reset pin and if your PC side host downloader supports DTR then it'll reset the MCU for you. That way the user doesn't even have to reset the power to download at any time. I've been doing that with PICs too. After 28 years of working almost exclusively with PICs, I'm now trying to move to STM32 (maybe later ATSAM too) to take advantage of the inexpensive STLink programmer/debugger (ICD3/4 cost $100s) and free software and compiler. Microchip wants $1000 per year for each of 3 compilers (XC8/16/32) which is a ripoff. Also, since ATM32 is now supported by Arduino, Python, C/C++ all for free, the choice is obvious.

Python has a lot more features and is much bigger than Flashforth so in your case it may be easier to get a project up and running using Python. Forth programmers usually write their own tools by extending the compiler and basically creating their own language. Back in 1987 Dataman introduced the Dataman S4 emulator/programmer which was an embedded FORTH product which became very popular. www.aliexpress.com/item/4000073336339.html

@@0033mer Yeah, the more extended (embedded) forth's I've come across are, MyForth and AMForth. MyForth looks like a bottomless rabbit hole I probably won't try. www.kiblerelectronics.com/myf/myf.shtml IIRC it is the only flavor I've seen that uses Forth for both sides of the embedded toolchain. I mean, the terminal emulator is written in GForth, so it's a forth system on both the host and client. I also looked into AMForth's shell code after a couple of emails with Mike (FF's auth). AMForth has a large level of integration between it's python based terminal shell(host) and embedded-forth(client). I wasn't talking about using python to program the μC though. I needed to use python just to modify the terminal to send and receive the binaries. Maybe the miscommunication is due to our different choices of OS. With Linux and a python based terminal script, modifying the terminal is easier than Flash Forth, at least as far as changing how forth sends and receives larger files. FF's python shell has no ability to receive and write the contents to a file. My other issue is that I don't like having to mess with the MPLabX side of Flash Forth. I don't want to recompile the base system for a PIC μC unless I have too. So, I think FF was probably the wrong choice as my first forth system to learn with. Mike's choice to lock out users from redefining words in Flash Forth really makes it difficult to follow Brodie's books after about half way in. Plus, I only recently found Peter's full documentation and repositories for his 2 flash forth pdf guides. There are a few differences between the version of the software Mike has on sourceforge and Peter's. Using Mike's version and his included libraries makes around 1/3rd of Peter's 5 page guide disfunctional. It's been a fun learning experience though. I'll be trying some other forth flavors soon. I have a MSP430F149 minimum dev board, on order, to try NoForth, and the STM32F4xx's to try with mecrisp. Have you seen any other interesting forth flavors to try? If you haven't seen it, Chuck is working on a forth that he has running on a current x86 intel i7 and is working on running it natively. He did a presentation a few months ago for the Sili. Valley FIG. It's on their YT channel :-) -Jake

You are probably uploading text too quickly. Set a delay for characters and end of line in your serial terminal software. I use 5 msec/char and 90 msec/line delays.

@@0033mer Your delay numbers sure did help; sure will speed me up. : = ))

Aliexpress has the best price but delivery time could be long. You can also get them here: www.universal-solder.ca/product/stm32-black-pill-weact-v2-0-stm32f411ceu6-100mhz-512kb-flash-128kb-ram/

When orientated so you can read the part number, pin 1 will be at the bottom left. There should be a dot in that location. To double check, all VSS pins (Gnd) are connected together and are in the same location on each side except for the side with pin 1. With an Ohmmeter and the pinout from the datasheet you confirm pin 1 then count around to the desired pin number.

When you program in Forth it becomes your own as you make up lots of words. I make up words as I go along so they won't be in the original dictionary. Check out the Mecrisp docs for GPIO manipulation. sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/MecrispStellarisUnofficial.epub/download

@@0033mer Thanks as I am new to Forth and working on MCU with micropython. Thanks for your advice. Let me check again.

Yes it can, DFU is how you do that

Here is a link to the documentation page: mecrisp-stellaris-folkdoc.sourceforge.io/ Here is a link where you can download Mecrisp: sourceforge.net/projects/mecrisp/files/

Search online for STM32duino. github.com/stm32duino/wiki/wiki/Getting-Started

@@0033mer Thanks a lot. I've noticed that one as well as others but i'm unsure what to go with. I've order 2 of these boards yesterday so i can move my project from teensy 3.2 since those have a locked (closed source) bootloader and i want to minimize the cost of my project. The reason of having an arduino style bootloaded is that the end user will not have access to reset buttons and they may want to upgrade their firmware via the usb port. So it needs to be easy and needs to be done from the same usb port that the device is connected. Btw, great video. I found the original designer that made this project and has all the info here: github.com/WeActTC/MiniF4-STM32F4x1

Select "Erase Chip" and do a Blank Check first, then try reloading the .bin file.

@@0033mer Thank you. Sorted! Just need to learn how to upload Forth programs now. The 'standard' image as downloaded does not seem to have the extras that are in your demo. Do you have an image for that?

When you start programming in Forth it becomes your own when you create lots of words. Start out simple with a Blink LED program and go from there. Check out the Mecrisp documentation: sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/MecrispStellarisUnofficial.epub/download

Yes ... DFU boot-loader at 2:26

Yes, in compiletoflash mode all words programmed in Forth will be saved in flash.

Thank you for reply. And kudos for all the videos you uploaded so far ! I love short and to the point content :)

No .. the USB is only for power and DFU bootloader.

You're welcome!

The three bootloaders are factory installed into the microcontroller and cannot be erased.

@@0033mer But I think I erased everything using STM32CubeProgrammer, before I was able to program it with Arduino IDE using SWD, but now I can't and only with STM32CubeProgrammer.

@@0033mer Also I can't use dfuse. I installed it and tried to get it to connect but it's not appearing on the com port.

Check out STM32duino when using the Arduino IDE with STM32 boards. www.mischianti.org/2022/06/09/stm32-programming-stm32f1-via-usb-with-stm32duino-boot-loader-2/

@@0033mer The bootloader is for the STM321, does it work for the STM32F4 ?

Check that you loaded the correct drivers.

Check out these links: www.forth.com/forth/ en.wikipedia.org/wiki/Forth_(programming_language)

Shh... 'the best kept secret in programing' can't be divulged to just anyone! Seriously, Forth is simple, efficient, expressive, fast and tiny - a compelling alternative to more prevalent languages like C. Mecrisp Stellaris is an excellent up-to-the-minute flavour of Forth. 'Starting Forth' is the classic beginners text. I wish I'd discovered it sooner.

First thing is to realize it is "FORTH", not "4th". Lots of data on the webs.