Substituted STM32H730VB for STM32H750VB on PCB due to chip shortage. 750 does not enter bootloader due to pin PB15. Is there a fix for it?

[g.roy619]

We were using STM32H730VB to drive a LED display in our project.

Pins 51 - 64 drive the LED display, Pin 30 controls the display power, and pins 24 - 25 act as the USART. We use CubeProgrammer to download the firmware.

This worked well and with no issues. However, due to the chip shortage, we swapped the H730 for the H750. While the display itself works fine, the main issue is that we cant re program the STM as it does not enter bootloader mode.

The root of the issue is the PB15 pin. If the pin is connected to the LED display, the STM does not enter bootloader. If it is not connected, it enters bootloader mode. We confirmed that this pin is the root of the issue, by using a jumper cable and substituting PB15 with PC12. In this case, everything works fine.

We wanted to know if here is any fix that does not involve changing the pin or disconnecting the display each time we need to re program the STM.

Thanks

Please Note:

1. There are no issues at all if we program it using Segger J-Link and CubeIde, however, we need the USART for our project.
2. We have tried changing the PB15 GPIO configurations, and also de initializing display pins before attempting to put the STM into bootloader mode. It still failed to enter bootloader mode.

[Tesla DeLorean]

The boot loader looks for transitions on a number of critical pins/interfaces, described in AN2606, the loader is in ROM/OTP so it isn't going to change it's behaviour

[TDK · Accepted solution]

The H750 listens for a UART signal on PB15, unlike the H730. No way to change that. You may be able to tell the LCD to be quiet on this pin while the bootloader starts.

It may also be possible to transmit on the interface you want before the PB15 has activity. This may require some tight timing, but once the bootloader is active on another interface, it will stop listening on PB15.

 

The chip is entering bootloader mode, it's just that once PB15 has activity, it doesn't listen to the other interfaces anymore.

[MM..1]

From your info seems you start boot from application directly. Other maybe more normal way is setup externaly BOOT pins and do reset MCU for example IWDG.

You try this?

[g.roy619]

I went through it once more, and noticed that in the known limitations section, it mentions that if PB15 is grounded STM wont enter bootloader mode. The display does seem to ground the PB15 pin, so, in the current setup, a 750H will not work.

Thanks for your help.

[g.roy619]

I was under the impression that as i am using USART 2, it wouldnt effect PB15. However, that does not seem to be the case.

I guess the best option for us would be to use another pin instead of PB15.

Thanks for your help.

[g.roy619]

Our main PCB has multiple MCUs. We have an additional PCB that we designed specifically to program the MCUs.

We first turn on the main PCB, let it run for an extremely short amount of time, and then put the STM32 into bootloader using the programmer PCB.

[MM..1]

Seems you do simple thinks over complicated way. , then why you dont use custom bootloader instead system?

[TDK]

I read that too and thought it was only for a very early version of the bootloader. Rereading this, it seems v9.0 is the newest version and that v13.x are earlier versions. What a weird versioning scheme.