cancel
Showing results for 
Search instead for 
Did you mean: 

Hardware changes required for programming through UART, USB DFU, I2C, SPI, and CAN bootloader interfaces

SA.17
Associate III
  • I am using STM32L072RB microcontroller,new to stm32cubeprogrammer,does all interfaces (UART, USB DFU, I2C, SPI, and CAN bootloader interfaces) support debug and programming ?
  • What hardware changes are required to implement programming features via these interfaces ?
  • Are these interfaces can be multiplexed . for e.g. same UART can be used to send data to PC and can be used to program microcontroller using PC ?
  • Is this software free?
  • Does my current microcontroller supports this or any specific requirements for using these interfaces for programming?
8 REPLIES 8

Try reviewing application note AN2606​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
TDK
Guru

The bootloader does not support debugging. It is meant for programming. The SWD interface (ST-Link) is meant for the usual programming/debugging.

If you feel a post has answered your question, please click "Accept as Solution".

https://www.st.com/resource/en/application_note/cd00167594-stm32-microcontroller-system-memory-boot-mode-stmicroelectronics.pdf

The ROM loader comes on the parts as delivered.

The most critical hardware consideration is NOT to generate noise on interfaces other than the one(s) you want to use. For example don't connect a GPS receiver to a USART the loader is looking for.

Use an interface you expose. If you have a RS232 port on product, connect the boot loader USART to that, so you can program in factory or field.

If you don't normally provide a USART port, expose one to pin headers or test points for factory use.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

The document explains connection for uart and DFU USB,can i have some circuit example for Boot pin and how to set and reset nBoot1 bit.

For normal operation BOOT0 should be pulled low externally. If using a BOOT button logic would be reverse that of the RESET

Sure there is an Option Byte programming example in HAL libraries, shouldn't need to change.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks ,but just for clarification

When i make BOOT pin high and program booloader using UART,then making Boot pin low will run this latest program from flash ,and i don't need to make boot pin high forever till i again need to reprogram.

BOOT0 pin just needs to be high across reset. Many boards, like flight controllers, have two buttons, you press the BOOT button, press and release RESET, then release BOOT, chip starts in ROM based system loader, connects via serial, or USB/DFU device.

BOOT pin latched at reset.

Must not let it float, will run into startup issues if supply slow to rise, internal core running at 1.2V, VIL/VIH thresholds a bit sketchy at that point.​

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

once this is done ,program will be in flash memory ?