Skip to main content
A
AHuss.2
Visitor II
January 7, 2020
Question

STM32F072 USB Firmware Update

  • January 7, 2020
  • 1 reply
  • 1145 views

I am using an STM32F072 MCU in my project and in the development phase, things seem to be working properly. The boot0 pin is pulled low and I can upload firmware via the ST-LINK debugger.

  1. When the product is released to the costumer, there are two possible ways to issue a firmware update. (1) USB (2) UART
  • USB: Since the USB DFU bootloader resides in the system memory, and I need to pull the Boot0 pin high in order to access it, it does not seem to be a viable option for future firmware upgrades.
  • UART: One of the UART is interfaced with a bluetooth module and I can issue an OTA firmware upgrade but again, the Boot0 pin needs to pull high in order to access the system memory where the bootloader resides

Q1: How do I issue a firmware upgrade without the need to make any changes to the Boot0 pin? My understanding is that I need to write a custom bootloader and place it in the flash memory that can be accessed upon power on since Boot0 will be tied low in the final product.

Q2: I also know that instead of writing my own bootloader, I can jump to system memory directly from the flash memory by reading a register value upon power on. However, I need to disable all the peripherals, clocks, interrupts and generally doing that is difficult and causes unexpected issue. Am I right here?

    This topic has been closed for replies.

    1 reply

    T
    Tesla DeLorean
    Graduate II
    January 8, 2020

    Difficult? It does require that you understand how micro-controllers function and execute code, and what your own code is doing, and might interact with other things.

    If you don't have the basics down it is going to be a harder slog. Review the ARM Technical Reference Manuals, review books on how boot loaders and staged loaders function. Review how to split the FLASH into multiple regions and how to put standalone code in each, and then transfer control or jump in/out of them.

    You are putting code on the MCU, you control everything happening there. Execution is going to start from a singular point, where it goes from there, and how many sub-applications you run is up to you. In the simplest form you split code such the boot loader starts first, and then you validate and transfer control to the application code, or stay in the boot loader and provide means/methods to update the area used for the application.

    Perhaps review the IAP (In Application Programming) examples, and how you can change the vector table location once you have started.

    Terms & ConditionsAccessibility statement