How to disable bootloader in unprogrammed device?

OLewi.1 · ‎2020-03-10

Hi,

We're using an STM32L47xx which connects to a number of other peripherals. On our first board spin, we can see the device enter bootloader mode. We weren't aware of the bootloader addition, so it wasn't accounted for during the early design phases. This drives various pins as output on an unprogrammed device.

The problem for us lies in our use of these pins. Many of them are used as inputs from other ICs. This means, that for the duration that the bootloader is running, up until the point we are able to program the device, these pins will be outputting in the wrong direction, parasitically powering other ICs. This is pretty dangerous and has the potential to do quite some damage to the board.

Just now, I'm seeing this as a bit of a chicken and egg situation. The bootloader won't disable until we program it, but we can't power it up to program it without starting the bootloader.

What is the best way to mitigate this (ideally without redesigning the whole board)?

Are there chip variants that don't start the bootloader when unprogrammed? Is there a way to force the bootloader not to start?

We have BOOT0 tied to ground, which when programmed is sufficient to stop the device kicking off the bootloader. It's just on virgin boards, where this is a huge issue as BOOT0 is overridden by the device being unprogrammed.

Is there a pin that could be looped to the reset line, that keeps the device in reset when the bootloader is running? Do we just need to add a manual switch to hold the device in reset until first programming? Can the device be programmed in some kind of low-power mode (i.e. power from the programmer)?

Any one else had this issue?

Any suggestions welcome.

Thanks

- Oliver

Andreas Bolsch · ‎2020-03-10

Depends on your board, and how you do the production programming: As you don't do it via the bootloader, and you don't mount pre-programmed devices, you do it via JTAG or SWD anyway? Pogo pins? Then adding one for NRST might not be that difficult (and would have been a good idea from the very beginning), and the programmer can supply that, too.

But certainly programming without VDD is not possible.

Anyway, I've never fancied the presence of an internal bootloader. The more protocols/pins it does support, the more likely it will interfere with board design sooner or later, and the less it does, the more annoying it is that it does not support the very interface/pins you've left ...