Skip to main content
Electrical Engineering

Return to Answer

deleted 2 characters in body
Source Link
brhans
brhans
  • 14.8k
  • 3
  • 36
  • 51

With ana USB UART bridge, you can see the virtual COM port in your PC and communicate with it, even if there is no firmware on MCU.

Also the MCU then does not need firmware that supports USB in any way and can simply communicate with UART.

Which means that since the F103 does not support DFU with factory bootloader, you are forced to write your own firmware and/or custom bootloader that supports USB enough to be able to update the firmware portion.

The factory bootloader does support UART so with ana USB to UART chip, you don't need any special custom firmware or bootloader, as you can simply boot (somehow, maybe with a button) into factory bootloader and program the MCU, and you are never locked out of the system.

However, using the MCU USB interface allows you to present itself as any device you want, such as keyboard, mouse or mass storage, etc, which isn't possible through the USB UART chip.

So it really depends what you want to do. If you don't use the USB for anything else than uploading new firmware, then you need to develop software yourself that you trust has no bugs when you upload the firmware. And then you need to implement the PC side too if you use your own custom protocol. This is something you don't need at all if you put a hardware USB UART chip there.

The other option is also not to use the F103. If you use an STM32 which supports USB in the factory bootloader, then you don't need the USB UART chip and can upload with existing GUI tools.

With an USB UART bridge, you can see the virtual COM port in your PC and communicate with it, even if there is no firmware on MCU.

Also the MCU then does not need firmware that supports USB in any way and can simply communicate with UART.

Which means that since the F103 does not support DFU with factory bootloader, you are forced to write your own firmware and/or custom bootloader that supports USB enough to be able to update the firmware portion.

The factory bootloader does support UART so with an USB to UART chip, you don't need any special custom firmware or bootloader, as you can simply boot (somehow, maybe with a button) into factory bootloader and program the MCU, and you are never locked out of the system.

However, using the MCU USB interface allows you to present itself as any device you want, such as keyboard, mouse or mass storage, etc, which isn't possible through the USB UART chip.

So it really depends what you want to do. If you don't use the USB for anything else than uploading new firmware, then you need to develop software yourself that you trust has no bugs when you upload the firmware. And then you need to implement the PC side too if you use your own custom protocol. This is something you don't need at all if you put a hardware USB UART chip there.

The other option is also not to use the F103. If you use an STM32 which supports USB in the factory bootloader, then you don't need the USB UART chip and can upload with existing GUI tools.

With a USB UART bridge, you can see the virtual COM port in your PC and communicate with it, even if there is no firmware on MCU.

Also the MCU then does not need firmware that supports USB in any way and can simply communicate with UART.

Which means that since the F103 does not support DFU with factory bootloader, you are forced to write your own firmware and/or custom bootloader that supports USB enough to be able to update the firmware portion.

The factory bootloader does support UART so with a USB to UART chip, you don't need any special custom firmware or bootloader, as you can simply boot (somehow, maybe with a button) into factory bootloader and program the MCU, and you are never locked out of the system.

However, using the MCU USB interface allows you to present itself as any device you want, such as keyboard, mouse or mass storage, etc, which isn't possible through the USB UART chip.

So it really depends what you want to do. If you don't use the USB for anything else than uploading new firmware, then you need to develop software yourself that you trust has no bugs when you upload the firmware. And then you need to implement the PC side too if you use your own custom protocol. This is something you don't need at all if you put a hardware USB UART chip there.

The other option is also not to use the F103. If you use an STM32 which supports USB in the factory bootloader, then you don't need the USB UART chip and can upload with existing GUI tools.

Source Link
Justme
Justme
  • 171.5k
  • 6
  • 135
  • 348

With an USB UART bridge, you can see the virtual COM port in your PC and communicate with it, even if there is no firmware on MCU.

Also the MCU then does not need firmware that supports USB in any way and can simply communicate with UART.

Which means that since the F103 does not support DFU with factory bootloader, you are forced to write your own firmware and/or custom bootloader that supports USB enough to be able to update the firmware portion.

The factory bootloader does support UART so with an USB to UART chip, you don't need any special custom firmware or bootloader, as you can simply boot (somehow, maybe with a button) into factory bootloader and program the MCU, and you are never locked out of the system.

However, using the MCU USB interface allows you to present itself as any device you want, such as keyboard, mouse or mass storage, etc, which isn't possible through the USB UART chip.

So it really depends what you want to do. If you don't use the USB for anything else than uploading new firmware, then you need to develop software yourself that you trust has no bugs when you upload the firmware. And then you need to implement the PC side too if you use your own custom protocol. This is something you don't need at all if you put a hardware USB UART chip there.

The other option is also not to use the F103. If you use an STM32 which supports USB in the factory bootloader, then you don't need the USB UART chip and can upload with existing GUI tools.