STM32F103C8 - Boot0 pin characteristics

[Peabody]

I have the DSO150 Shell kit scope, which uses the STM32F103C8 processor at 3.3V.  JYE-Tech provides a way to update the firmware, but it requires opening the case, connecting leads from an external USB-to-Serial module to the GND, RX and TX through-holes, and solder-bridging Boot0 (to 3.3V) and Boot1(to GND).  Then after flashing you have to undo all of that.    We're on about the sixth update now, and this is getting old.

I would like to embed a CP2102 USB-to-Serial module in the existing circuit so all I would need to do to flash firmware is connect a USB cable.  The GND, TX and RX connections are straightforward, and it appears that Boot1 can be tied to ground and left that way during normal operation.

That leaves Boot0, which needs to be high on boot to enter the bootstrap mode.  I had thought I could tie Boot0 to the 3.3V output of the module.  So I could plug in the live USB cable, then power up the scope.  But initially that would mean that since Vdd is at ground when the scope power is off, I would be applying a low-impedance Vdd + 3.3V to the Boot0 pin.

I can't tell from the datasheet whether doing it this way would cause too much current to flow into the pin - either through the protection diode or otherwise.   Boot0 appears to be a 5V tolerant pin, but I assume that's with Vdd at 3.3V.  So I don't know.

Does anyone know for sure if this would work?  If not, how would I go about testing it non-destructively?

I should say that another approach would be to use the module's 3.3V output to power the ST, and leave the scope power switched off.  Then everything would come up at the same time.  But I don't know if the module can power all of the things powered from the 3.3V rail.  Also, these modules don't behave well when they are powered down (when USB isn't connected).  They can sink a good bit of current.  Of course I could insert a diode or p-channel mosfet to prevent that, but that just complicates things more.  So the original plan would be best if it won't damage anything.

[C]

Why not just control the Boot1 with an output from the CP2102?
DTR & RTS are ouputs that can be controlled from PC.
Could even add a series resistor to limit current.

[Peabody]

Why not just control the Boot1 with an output from the CP2102?
DTR & RTS are ouputs that can be controlled from PC.
Could even add a series resistor to limit current.

Thanks for your post.

The software used for flashing is provided by ST.  I have no way to change it to make it control DTR or RTS.  But from reading the datasheet, Boot1 can simply be tied low permanently.  Its state only matters if Boot0 is high, which only occurs during flashing.  So tying it low shouldn't interfere with normal operation when Boot0 is low.

Since posting I've studied the datasheet some more, and I think it will be ok to bring TX, RX and Boot0 high before powering up the processor, and resistors shouldn't be needed.  But I'll try to do some current measuring tests tomorrow to see if I can confirm that.

[C]

If you check you might find that the states of DTR & RTS change when softwer starts talking to them.

When ST software connects to the port these could change. Could change when the software actually starts sending data.
You might be able to get a Reset & Program.

[technix]

If you check you might find that the states of DTR & RTS change when softwer starts talking to them.

When ST software connects to the port these could change. Could change when the software actually starts sending data.
You might be able to get a Reset & Program.

If that is your concern, you may be able to code up a USB-Serial with proper RESET and BOOT0 control using STM32F042F4 (likely the cheapest and smallest ARM microcontroller with USB.) Implement CDC ACM for the virtual COM port, and either hijack the control lines or implement an additional USB HID interface to reset.

[westfw]

There are a bunch of Arduino sort-of-compatibles with this CPU, and I don't think any of them has implemented automatic control of the BOOTn pins (they usually get jumpers, and are used to load a USB-based bootloader.)  They might be worth looking at, though.
http://wiki.stm32duino.com/index.php?title=Category:Boards