Stm32 Flash Loader Download

[Antionette Eastin]

Ihave had some success following the "MOOC - External QSPI loader how to" youtube video series by ST and the example code for memory mapped QSPI available in the "STM32Cube MCU Package" downloaded from ST website.

However, when I use the created External loader (based on the example code and video series) I am able to read the FLASH using the STM32 CubeProgrammer, but the first 2 bytes are always 0 even when the flash has been erased only.

I did actually find the examples you mentioned which look very similar to the "MOOC - External QSPI loader how to" video series done by ST referenced from original post. Also, I have attached a log-file from STM32 Cube Programmer with "Verbosity Level 3" to the original post.

I was looking for a tool that was able to bootload an STM32F767 microcontroller via USART which I thought I found when I came across the STM Flash Loader Demonstrator (version 2.8.0). However, there was no '.STMap' memory map file for this processor family, the closest was STM32F74X/5X.

STM32F767 (see attached) which allowed me to successfully connect to my micro using the Flash Loader Demonstrator. However, I cannot perform an erase, program or download. The error message that I receive says 'Fail. Check read/write protections'. However, when checking the flash readout and write protections they are disabled.

Thank you for your fast reply and for the new version of the flash loader tool - I will let you know if I have any problems with it. As it turns out I have managed to put my stm32F767 into an odd state by using my modified '.STMap' file. The NRST line is being pulled low over and over again. I have verified that there is no other MCU external circuitry that is causing this to happen. I can still program and execute code using TRUEStudio and the NRST line is fine (stay high) when the processor is halted or if you step through code line by line. However, if you remove break points and continue execution the NRST line starts to be pulled over and over again.

If I use the STM32 ST-Link Utility v 4.5.0.0, open the file RAK5205_Blink.hex and program the MCU, it ends correctly and the program runs without problems on the board. If I want to completely erase the Flash memory, it does it correctly with this indication:

Now, if I open the STM32CubeProgrammer v2.1.0, open the same file RAK5205_Blink.hex, the ST-Link v2 is recognized and connected correctly, read the memory of the MCU without problems, but when I want to program it in the same way than before, it shows the error, "Flash loader can not be loaded".

You must disable the read protection. The easiest way to do this is with the ST tool "Flash Loader Demonstrator". After a few next clicks you will find the option "Disable Read Protection" there. After that, you can check the "Option Bytes" with the STM32 ST-Link Utility. After that debugging ist running like a charm.

I have no idea, what the source of this error might be. Since flashing and executing the program are both working fine after using the older ST-LINK Utility, the issue should be located inside the Toolchain / STM32CubeProgrammer.

I'm working with a proprietary board using a stm32f107 and I would like to flash my soft into the ship by using RS232. To do that I have a RS232 connector which can be connected to USB and then I can collect Rx,Tx and GND from the DB9 connector.

My trouble is when i'm trying to flash my soft with Flash Loader Demonstrator, I'm receiving this error : 'No response from the target, the Boot loader can not be started. Please, verify the boot mode configuration and the flash protection status, Reset your device then try again...'.

I connected the Rx and Tx from the DB9 to the Tx and Rx of the stm32f107 (Rx->Tx, Tx->Rx), all my power supplies seems good and I did put the BOOT0 pin to GND to enter in the boot mode. I even try on an other board in case the first one was defective.

Do you connect to the correct port? According to AN2606 the bootloader only works on USART1 and 2. You should also check that you apply the correct pattern to activate the bootloader (see AN2606) which is Boot0 = 1 and Boot1 = 0 for the STM32F107.

Flash Loader Demonstrator in that it's configuration of the DCB for no handshaking is (was?) incomplete. I reported this in another thread, but ST never commented andI don't know if they corrected it or not. If this is the problem, a workaround is to open the comport with another application (possibly a terminal program such as TeraTerm) and configure it for no handshaking, then close that application, then runFlash Loader Demonstrator.

Note to ST: The incomplete DCB configuration for no handshaking (FlowControl == false ... actually within an 'else') is in the file 'rscpp' in the functionCRS232::open(). There is more to it than just configuring fDtrControl and fRtsControl to FALSE (see my comments in

Flash Loader Demonstrator. Then run the same test for software flow control. Another suggestion, display the version number from within the program on the first window prior to making the serial connection. I don't think the software version is displayed anywhere within the program.

When I tried to flash the soft on the board I can see something on the Rx of the STM32f107 but nothing is getting out from the Tx of the ship. So I checked with Hyperterminal that the data are correctly send by putting a jumper on tx and rx and I correctly receive the message that I'm sending.

I've found out that flashing a FW with Use Flash Loader checked everything goes smooth. After that, if I try to flash on the same device another FW with Use Flash Loader unchecked, the flashing process goes smooth but I can't debug and IAR shows a series of verify error like

If Use Flash Loader is checked, the IAR debugger loads a tiny flash loader application into the RAM of the target MCU which then in turn is able to program the user application into the target flash. The flash loader application is typically implemented specifically for a MCU device family (like STM32L1), because each device (family) has it's specific way on how the flash memory needs to be programmed (unlock mechanism, timing, etc.). The IAR workbench ships with a large collection of flash loaders for all supported devices. Refer to chapter Flash loaders in the IAR C-SPY Debugging Guide for a more detailed description of the flash loader mechanism.

If Use Flash Loader is unchecked, the IAR debugger instead relies on the debugging probe to be able to program the target MCU's flash memory. It depends on the specific debug probe (driver), whether it is able to program a specific device.From my experience the popular Segger J-Link debug probes are able to program nearly all ST STM32 MCU devices without Use Flash Loader, while the IAR i-Jet debug probes lack this ability - to name just two probes.

Unfortunately, the IAR EWARM debugger does not issue a warning (or error) message, when the configured debug probe is not able to program the specific target MCU. Instead it seems to assume that programming succeeded. Only if the option Verify download has been enabled, the debugger will check whether the user application has been successfully flashed to the target.

In your case verification of the download fails with a blank device, because your debug probe is apparently not able to program the target MCU flash memory without a flash loader. You need to enable the Use Flash Loader for the debug probe in all your projects.

I'm trying to make a custom external flash loader for my STM32F746 uC based board and i found some templates for this purpose from this link that is belongs to the ST workshop on this YouTube link. So when i dug into the corresponding files i saw that in a linker script file named linker.ld the RAM memory region is defined from base address 0x20000004 though i know that the RAM memory region in STM uCs starts from address 0x20000000:

So the problem is why we must define RAM memory address from 0x20000004 for external flash loader algorithm to store in and not from 0x20000000 instead. Could anyone please help me to explain the reason and tell me that what will happen if we do the:

A year ago I made an external flash loader and that works ( -external-loader/pull/13). I now ported the loader to the STM32H735IG. I use a serial port to print debug messages at certain points. While the flash loader works I do get hardfaults(in the loader, not the application) under certain conditions:

If I connect in STM32CubeProgrammer and then open memory viewer to 0x90000000 and then click disconnect. It doesn't occur when I did not open the memory viewer to 0x90000000 since that doesn't lead to an init of the loader. The flash loader will properly flash the internal and external flash and optionally runs the MCU. So it works, but I do see a hardfault error printed:

So HFSR[31/]DEBUGEVT is active.

And DFSR/Debug Fault Status Register is non-zero. I did not find any documentation about this register for the Cortex-M7. In core_cm7.h I found this means the following bits are set to 1 (and in I found their meaning):

It appears the problem doesn't occur in my application if I initialize OSPI1 before OSPI2. But it still occurs in the flash loader. I found this topic that seems to be related: -mcus-products/stm32-cube-h7-hal-ospim-config-corrupts-previous-port/m-p/126073

Ospi2 is HyperRAM and it is memory mapped. If I initialize OSPI2 first, but do not enable memory mapping the error doesn't occur. So the problem occurs in HAL_OSPIM_Config after OSPI2 is memory mapped. I think a similar thing happens in the flash loader but in this case it is OSPI1 that is memory mapped when the error occurs. HAL_OSPIM_Config doesn't like to be called when at least one OSPI is memory mapped.

HAL_OSPIM_Config does this automatically, but maybe it does it improperly. I will check if I can make some type of fix.

"So I advise you to avoid the OSPIM configuration issue to call HAL_OSPIM_Config only one time at boot."

3a8082e126