I'm going to use STM32f103 as a main microcontroller and ESP8266 as a Wi-Fi module in my project. These 2 chips are in contact with each other via UART.
I have a server that contains the "version2.bin" file. I can download this file with ESP8266 but how should I update STM32 firmware with this file?
In other words, how can I perform OTA?
STM32F1 have an embedded bootloader you can use through uart. Details are here: AN2606 and here AN3155
You can make your own: Partition your flash and save one part for the bootloader and one for the application. The former should check for some signal to update the latter. Afterwards the bootloader should jump to the application.
In theory you can program also by using the debugger protocol but never saw it done, I suppose it's simply insane to do that this way.
Related
I have designed and assembled a PCB. All connections are fine and leds are blinking when i open the CUBEMX. But I don't know what to do after this point. Do I need to put some drivers before using DFU?
If so, i don't have an ST-LINK Programmer how can i use the only input for this pcb (which is PB11,PB12 as AN2662 suggests). Its also interesting that device is responding to CubeMX . Does device has any code in it?
MCU :
STM32F405RGT6
Your question is not clear. But i will try to answer to your question with my understanding from the question. First thing that you need to find the datasheet of mcu. Now, you can able to find related pins for programming. Using these pins, you can program your hw.
if you want to put dfu mode to your hw, Please check "Application Note 2606 STM32 microcontroller system memory boot mode".
Also, i wrote post about system memory bootloader, here is the link: https://engineeringvolkan.wordpress.com/2020/05/08/1928/
If I understood well, you want to learn how to upload code into your uC. If you are not familiar with DFU, I suggest that you can use ST LINK V2. However, the important point is whether, or not you put output terminals for SW pins (SWDIO, NRST, SWCLK, SWO).
For the DFU, you should check Bootloader properties and bootloader configurations specifcally related to your uC. After these, you can watch this video EEVBlog STM32 DFU and inspire from it.
My STLINKV2 is not working anymore, not detected by Linux, it failed after the first successful flash. I ordered a new one but it will take 60+ days to arrive. Meanwhile I have heard on Youtube you can program Bluepills directly by connecting cut open USB cable to certain pins and then using a jumper. But I cannot get any precie information on this, is this really possible and how?
You should use the embedded bootloader. You can flash it through several interfaces. Look at AN2606, maybe you can find an already written flasher. Good luck STM32CubeProgrammer handle it.
If you intend to program it through usb, look also at AN3156 all protocols document are referred in chapter 2 of AN2606
THOSE AREN'T CUT OPEN USB CABLES they are USB to serial adapters for arduino's bootloader
They connect them like this:
The problem is that this requires the Arduino STM32 bootloader to be flashed in it.
Another option will be to use STM32CubeProg this program allows you to program your stm over
Serial
SPI
I2C
USB
You'll need to set the BOOT0 and BOOT1 pins to the correct value (HIGH slash LOW) to allow it to go in flash mode during boot.
Here is semi outdated tutorial which tells most of the steps to program a STM using serial. (the Flash Loader Demonstrator is outdated and you should use STM32CubeProg)
i'm using STM32 as my microprocessor along with I2C EEPROM for storage and ESP8266 for Wifi
How can i download an update binary for the bootloader to flash using ESP8266 although the firmware file will be larger than STM32 Ram so i can't load the file from the ESP8266 in one chunk ?
I suppose that you want to update the stm32 firmware.
In this case allow to upload a new binary for the stm32 to the web, store it in the esp8266 file system (it must be bigger than stm32 flash size).
After that, enable flash memory writing, set an small protocol for update stm32 from serial comm from esp8266 the file to stm32 flash.
Remember that all functions that are used to update the stm32 flash must be in RAM.
I'm doing a project for stm32f4 and esp8266 and I will do exactly this.
OPTION 2:
If your program binary size is under 50% of stm32 flash size, then use the above half of the stm32 flash memory to store the new program, after reset, check if there is something there, and if it is then update (this is what i'm doing actually in stm32, very secure method to update since only stm32 cpu is used for update and it is very fast).
I suppose that you have two firmwares on the STM32 flash. First one is boot loader and the second one is your application. Your boot loader gets new firmware over serial interface of the ESP8266; so you can use flow control pins to halt communication until you write the data into flash memory.
I use that combination, stm32 and esp32/esp8266, for now i have not used firmware upgrade from esp (my stm32 supports it but I have not needed it for now).
The easier way is to set a serial protocol between both cpus. I'm using half of the stm32 memory for code and half for updating. What I do actually is using the communication protocolo is copy the file to the upper half of the flash memory. After when i reset the code i check if there is a firmware ready to be updated, then I copy from top half of flash to bottom half.
With this system, you can check if all is ok and the update process with take few ms. After you have this system tested (using for example a PC) you can try to do it from your esp, but it is just as easy as repeat the process.
My tip about the esp8266 is to download the file to a spiffs. If you are not using spiffs, use it, create a drive a little bigger than your memory.. for example if your stm32 firmware binary is around 60kb, and your target cpu is 256, use around 160kb for it.
There is another way, it is download the html file in chunks and then send them to the top half of the cpu, it is not very complex. I would requests chunks with the same size of the block size of your comunnication process (in my case i'm using 256b or 512b, i dont remember at this moment).
Anyways if you have enough spiffs size download the file, update the stm32 cpu, delete the file and send a reboot.
Dont forget to add a crc for data transmision between stm32 and esp8266
Btw you dont need to download it to ram , since update is used rarely and you have limitations like number of times that you can update a flash memory, so, it is not a problem to save it to flash in the esp8266 neither the stm32
Best regards
We have a FTDI device, FT2232H and an EEPROM M93C46-WMN6TP. Is there a utility or a way to program the eeprom in Linux using command line? We do not have provision for GUI in Linux or for connecting it to a windows system.
There is a sample EEPROM folder provided with the driver package that cab used for programming the EEPROM device (/release/examples/EEPROM/write/ )
Write can be checked used the read program in /release/examples/EEPROM/read/
You can absolutely program an EEPROM with a FT232H, but you will have to write your own program.
I am more a Windows person, but the code should similar on Linux.
I just sent a tweet yesterday doing just this with an FT4222 board
that I will use for my USB device Nusbio v2.
https://twitter.com/MadeInTheUSB/status/808868754146914304
A video experimenting with the FT232H
https://www.youtube.com/watch?v=8i8_EFs_j0I
The EEPROM M93C46-WMN6TP protocol seems to be SPI
see datasheet page 6
I suppose you may already have an FT232H evaluation board, so once wired on a breadboard to your EEPROM all the 4 SPI wires (CLOCK, MOSI, MISO, CS) you can start talking to the EEPROM.
Unfortunately the source code from one EEPROM to another thing can change.
I know very well the I2C 24LC256 family and the SPI 25AA1024.
Some of my code is available on github, this is for the SPI EEPROM 25AA1024,
that should help
MadeInTheUSB.Nusbio.SPI.EEPROM_25AA1024
MadeInTheUSB.Nusbio.Components/EEPROM
You can find a 100% already made solution hardware and software at
Nusbio Thumbdrive
Using the source mentioned above.
My question is, if I manage to develop some kind of bootloader and flash it (is it called that when you put a bootloader on an MCU?), and it works horribly, can it brick the MCU entirely, making it completely unusable, permanently?
The reason I'm asking is that I've been tasked to develop a bootloader for the STM32F407. Problem is, I don't know anything about bootloaders or anything of the sort, which means that I have a lot to learn.
I appreciate any answers, thank you!
In short no you cannot brick a microcontroller with a bootloader.
In the end bootloader is just a firmware and can be erased away using the programmer via SWD
Erase the flash and your controller is as good as new
In general, absolutely, I have a collection of bricked microcontrollers, every so often I get lazy and there goes another.
It is very specific to your microcontroller and family. For example, pin count is very important, as much bang for your buck as you can get, if your microcontroller relies on certain pins for in circuit (or even in a programming fixture) and those pins can be repurposed by software. For example jtag pins that can also be gpio pins. And your code for some reason uses them as gpio pins, AND the design of the chip is such that they cannot use the jtag interface when the chip is in reset, then you can get bricked.
Another very easy one is the pll or clocks in general. If/as you develop code to initialize the clock system (assuming you choose to do that, even if you use chip vendor supplied code) and you have a bug that switches the chip over to a clock that you have not properly initialized or isnt there, it might brick.
Now some chip designs, many, help you out in various ways. The AVR family in general there is a programming mode that happens while the chip is in reset or is related to reset such that whatever code is in flash cannot affect its functionality, you can have a bad board design, sure, but your code cannot prevent it from working. Another method is a "strap" a pin (or pins) that is dedicated to a boot function, set one way normal boot, tie it the other and it goes into an alternate bootloader. This is what you have on the stm32 boot0 and sometimes boot1 depending. that is your get out of jail free card for that chip family, if you brick your chip (pll/clock or mess up the SWD pins by using them as gpio), you "simply" change boot0 and it boots into an internal bootloader (which AFAIK you cant mess up) which is known to work. From that bootloader you can use SWD (chips not bricked now) or the bootloader itself (always serial, sometimes usb or other is supported). NXP similar deal. Atmel ARMs used to have (do have) SAM-BA now they really only support SWD, you can get some samba code and try to lock it into the flash, but way too easy to unlock and or trash that flash, so that is a fail on their part.
As part of your system design if you dont have one of these built into save you from bricking features (like boot0 on an STM32), then I recommend you add one. Very early code initializes a dedicated gpio pin as a strap into your software, if that gpio pin is pulled one way do a normal boot, if pulled the other then spin in an infinite loop or jump to some other guaranteed to not be buggy code. Not a complete guarantee that you wont build the project wrong and trash this code, but it at least allows you to develop your bootloader/project and not brick a tray full of parts/boards as you work through the peripherals that can brick it.
Note letting smoke out of the part is another way to brick it as well, and that can/does happen from time to time as well.
Lots of examples on how to boot an STM32, plus various code from ST that you can use as a starting point as well. (all of which is of various quality, you get what you pay for). Their docs are good, better than some of the competition, not difficult at all to boot and configure their peripherals, sometimes easier than trying to use a canned library. YMMV, you should try various solutions. But if you are new to this, bricking is highly likely, fortunately you have a chip that you cant brick so long as your board design breaks out the boot0 pin. For a prototype board for an STM32 I prefer to have a boot0 button and a reset button, just reset resets the chip and runs, hold boot0 and press reset and it goes into the bootloader. both have to be wired in properly with the right pull up or down as needed for this task. or a jumper works tie boot0 directly high or low then pop reset, costs you more time, but works.
Yes You can brick the Micro controller to never recovered state. I did this and i did it in STM32F427.
Bootloader is all about carefully selecting Clocks, Peripharals and Interrupts priority. if you do this, there are less chances to brick the controller. Also test everything before release your code as some companies wants to save proprietary information to be saved so they blow up the JTAG lines, the only way to program is via Bootloader and if it is not perfect, voila, you just bricked the controller.