STM32F405RGT6 fails to enter bootloader sometimes

[SKana.5]

I'm using STM32F405RGT6 as a Main controller on the board for our product.

When we flash the FW to STM32F405RGT6 via FT232RL, it fails to enter bootloader mode sometimes. Failling rate is around 40-50%. I observed signal behaviour about Reset(DTR) and BOOT0(RTS) with logic analyzer. In success case, its behaivor looks fine but we saw the steep voltage drop on Reset(DTR) in fail case. I tried putting pull-up resistor(10K) on DTR line but it didn't work. Actually, I have no idea about that voltage drop and what is going on the STM32. Is it not hadware related issue?

​

I'm using stm32flash v0.7 to flash FW.

GPIO sequence is set to “-rts,dtr,-dtr:rts�?

baud rate is set to 230400

Basically, following the application note(AN3155 USART protocol used in the STM32 bootloader) below.

[waclawek.jan]

The short pulse on NRST may come from the mcu itself - a software or watchdog reset.

Do you use the watchdog in your firmware?

JW

[SKana.5]

Hi JW,

Thank you for your comment. Yes, we are using internal WDT in our firmware. We will try to enter bootloader and flashing firmware with disabling WDT.

However, first of all, the problem is STM32 can not enter bootloader mode sometimes and tbh I'm not sure this short pulse is relating to this problem or not.

[SKana.5]

I disabled internal WDT and tried entering bootloader but still it fails with same rate.

I captured the datalink packet and found that FT232RL sends 0x7F and STM32 reply 0x79 in success case but FT232RL sends 0x7F and STM32 doesn"t reply anything in fail case.

So, is this a issue on STM32F405 side?

[Peter BENSCH]

The picture of your circuit is not very legible. Two components are drawn between /DTR and NRST: D110 (Schottky) and R103 (?). Which of these is fitted?

Second point: according to AN3155, section 2.2 the maximum baud rate is given as tested with 115200. Please check if you get better results with 115200 instead of 230400.

Regards

/Peter

[SKana.5]

Hi Peter,

Sorry for making you confused. D110 is not mounted. R103 (0ohm resistor) is mounted. Okay, I will try 115200 baudrate.

BTW, I have a question. Now I am using 16MHz external clock for SMT32F4. If I use 8MHz external clock instead of 16MHz, are there any chance to improve this problem?

[Peter BENSCH]

Pin /DTR of the FT232RL is a push-pull output, i.e. it outputs an active H in the inactive state. Pin NRST, however, should only be pulled down to GND when a reset is triggered. This is partly due to the internal pulse generator at NRST, which can also be an output for internally generated resets (see reference manual RM090). You should therefore remove R103 and mount D110.

Your problem has nothing primarily to do with the frequency of the crystal, but with the set baud rate of the host, which as mentioned is only guaranteed with 115200 bit/s.

Regards

/Peter

[SKana.5]

I tested flashing 20 times with several pattern. Chaning the Baudrate looks not working.. It still fails sometimes.

No.1 (fail rate 25%)

Baudrate is 230400 bps

R103:mounted, D110:unmounted

No.2 (fail rate 25%)

Baudrate is 115200 bps

R103:mounted, D110:unmounted

No.3 (fail rate 30%)

Baudrate is 115200 bps

R103:unmounted, D110:mounted

No.4 (fail rate 45%)

Baudrate is 230400 bps

R103:mounted, D110:unmounted

[SKana.5]

I probably found the cause of this.

I'm using PB5/6 for CAN interface and Battery(Toshiba:FP01101MCB01A) is connected to it.

Actually, when failing to enter bootloader via USART, STM32 detected some frame on CAN and went to CAN bootloader process. (refer to the flowchart on attachment file).

As a experiment, I removed the battery from CAN interface and trid to enter bootloader and wrote FW.

Fail rate was 0 out of 20 times. I guess CAN communication happend during bootloader entering process and when STM32 could not catch 0x07F, STM32 go to CAN frame detection process and detected CAN fram and not come back in failure case.

Do we have any workaround to do this without changing the current electrical schema?

[Peter BENSCH]

Now the picture becomes clearer. If your battery is connected to CAN2 where the bootloader expects a host and you don't want to use your own bootloader, you will have no other choice but to redirect these connections to PB12/13.

Since the built-in bootloader cannot be changed, it should always make sense during project planning to check the interfaces mentioned in AN2606 carefully to see whether devices connected to them can interfere with the bootloader process.

Regards

/Peter

[waclawek.jan]

Oh, so it's this. Nice catch.

I was confused by the reset pulse mentioned in your initial post.

You should review signals on all pins mentioned in AN2606, regardless of whether such signal is intended to be in the "protocol" for given pin, e.g. if there's some "randomly changing" signal on say PB11, under adverse conditions the bootloader may evaluate it as valid UART3 bootloader entry, and then your UART1 bootloader wouldn't work either.

It may be better to use the built-in bootloader only for the initial programming, and then use a custom bootloader which works exactly as you intended.

JW