STM32G0B1 system bootloader and GPIO conflicts

Connecting output to output pins is always dangerous. If this is not avoided due to the lack of pins, it is possible to put a resistor on the output of the external device and thus limit the possible current at different levels to an acceptable value.

One way to avoid conflicts due to system bootloader inadvertently activating an interface which you don't intend to use, is not to use the system bootloader at all... (i.e. use SWD for initial programming, and it there's a need for in-field reprogramming, write your own bootloader, maybe even using the system bootloader's protocol).

JW

Thank you both for the time you take to answer.

Of course we know that direct output + output is not good. The problem here is that the system bootloader is using a lot interfaces and configures the IO for all at the start. We have never thought about the system bootloader being an issue because we never use it, hence the problem rising now.

@waclawek.janYes we use SWD for programming our BL and our APP at the same time. The issue is that for the small amount of time between power on and the SWD kicking in, since our flash is empty the system BL will start and the pin conflict will last for some time (like 1-2 seconds). In the end we fear that the pin in conflict is getting damaged sufficiently that it might work during production but will fail afterwards.

Best regards,
Kraal

> The problem here is that the system bootloader is using a lot interfaces and configures the IO for all at the start.

Does it?

Bootloaders I looked at switched on pullups/pulldowns, but unless they sensed *something* on their respective "Rx" pin, they did not switch on push-pull on "Tx" pin.

The only" problem is then that *something* may happen inadvertently if given "Tx" pin is connected to some external circuitry which is "alive" in some way.

Unfortunately, details these of the bootloader are not very well documented; but the bootloader can be single-stepped and/or disassembled to see what's going on.

> The issue is that for the small amount of time between power on and the SWD kicking in, since our flash is empty the system BL will start

I always use NRST as one of the the SWD pins and I recommend you to do the same.

I admit that I did not have much success in coaxing STLink-Utility to consistently handle NRST upon my comand, but I also did not pay too much effort to that as our designs never required that much care. At the end of the day, would this be critical and wouldn't some combination of Utility or CubeProgrammer behave consistently, I'd spend time to implement my own method to hold the circuit in reset while programming. Why, even a manual pushbutton would do, if production volumes are low.

JW

We have already made a new version of the PCB with a 1k in between the 2 pins. I was hoping for an intermediate software solution for our current 500 pieces batch.

According to AN2606, the SPI Tx pin (the one that is problematic in our case) is set as a hard output with idle level high as soon as the SPI DMA_Tx is activated (which, according to the diagram, is right on the startup). And of course our opamp output is at 0 by default, yey.

We always use NRST with SWCLK and SWDIO, but apparently (correct me if I'm wrong) you can't write to the register through SWD under reset.

Kraal

You then should be able to use Connect under Reset, and then start programming, which should prevent the bootloader from running ever.

Can you observe the SPI_Tx pin to turn to hard output one, perhaps on the devices with the series resistor? If yes, that might perhaps serve as a verification that the programming with reset works as intended (or not).

JW