Problem entering USART1 boot

[MSipo]

We are using an STM32L151RE.

We have problem entering USART1 boot on some of the boards. We set RESET low, BOOT0 high, then set RESET high. Then we send 0x7F on USART1 and get 0x79 as reply (on the working boards). The non working boards does not reply to 0x7F.

BOOT1 is connected through 10kohm to ground.

All boards can be programmed through SWD, no problems there.

We have verified RESET and BOOT0 all the way to the MCU pins. And we can also see that the application reacts to RESET and BOOT0. The application runs only when BOOT0 is low and RESET is high (som that should be proof for functioning RESET and BOOT0).

This MCU can boot into bootloader from USART1 and USB (USART2 boot can't be done as this chip does not have the pin PD5 and PD6).

How can we troubleshoot this?

I have pinpointed where in the bootloader it goes wrong. The bootloader reads the USB_ISTR.

The value is 0x2000 on the faulty board and 0x0900 on the board that works.

It is the SUSP bit that is cleared on the faulty board. And I guess this makes the bootlaoder boot into DFU as it think there is something connected to the USB.

[TDK]

Possible that the chip sees another peripheral and boots into that bootloader before you send the 0x7F. Write a program to make sure the USART1_TX/RX pins can be toggled independently.

[MSipo]

We control the BOOT0, RESET, USART1_RX and USART1_TX with an FTDI232RL chip. We can control all pins. We have verified these pins.

[MSipo]

I tried on a working board and put a breakpoint at 0x1ff001aa where the bootloader has seen a zero on PA10. The run halts on this breakpoint when I send 0x7F to the MCU. All ok. But on a non working board I can't get it to halt at that breakpoint. I suspect that the boot loader has taken another path.

[TDK]

You could pause the "non-working" chip to see where it's at. The bootloader is going to go to the first supported peripheral it sees.

You're also mixing up USART1 and USART2, maybe the USART2 in your reply earlier was a typo.

[waclawek.jan]

And what is connected to the USB pins?

JW

[MSipo]

Yes, it was a type because someone had named it RX2/TX2 on the schematic.

[MSipo · Accepted solution]

The problem is now fixed. We removed a 100kohm pulldown on PA12.

Is there some guide on how to connect other things to PA11/PA12 so it doesn't interfere with boot selection (false DFU boot)?