STM32G0B1 system bootloader and GPIO conflicts

[Kraal]

Hello,
We have designed a board around a STM32G0B1CB where almost all the 48 pins are used for different stuff (lots of analog inputs, communication and PWM).
It is not our first design with STM32 uC, but we are facing an issue here and I would like to hear about your experience if you encountered the same.
To recap, the G0B1 uses a lot of possible comm interfaces with pins configured as outputs (obviously). Unfortunately for us, we did not take this in account, so we have an op-amp output that is directly connected to SPI1 MISO (which is also an output). This bus contention forces the pin to output more current than it can.
My question is : can it destroy the uC pin if this contention lasts for some time ? I saw high power consumption on my bench power supply for several seconds before loading my firmware, and the input does not seems that have suffer. The problem is that it is a product that will go in the field and I'm wondering what are the chances / risks of an I/O failure.
Please note that we are using the pin in analog mode, so maybe it can destroy only the digital part ?

Thank you and best regards,
Kraal

[ONadr.1]

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.

[waclawek.jan]

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

[Kraal]

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

[ONadr.1]

If your device production is only a few prototypes, then add a resistor of approx. 1k between the pin and the output of the comparator (which is mostly feasible). That way you will limit the current and when the pin is configured as an input, the resistor will have almost no effect on the connection of the comparator to the pin. For production, it will be necessary to correct the PCB and install one extra resistor.

[waclawek.jan]

> 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

[Kraal]

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

[waclawek.jan]

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

[Kraal]

Hi Jan,
Good point, I will try both suggestions. I can rework one of the board with a series resistor and see how it goes.

Best regards to both you and @ONadr.1 , I'll post an update once I get to do this test.
Kraal