Unable to enter boot loader mode on STM32F103C8T6: Transmit pin remains as input

[Jim Seymour]

Posted on August 23, 2017 at 23:58

We're trying to activate boot loader mode on an STM32F103C8T6.We have an outside device drive the BOOT0 pin HIGH before we apply power.  Then, we send the initial 0x7F byte to the STM at 115200 bps, 8 data bits, even parity.

However, the transmit pin from the STM seems to remain as an input.

Can someone confirm that the TXD1 pin from the STM normally goes high when the boot loader is activated?  And if so, at what point in the sequence? (at power up when it sees BOOT0 high? or only after it receives the 0x7F?)

Thanks.

[Tesla DeLorean]

Posted on August 24, 2017 at 05:23

Look at a DISCO or NUCLEO board.

The System Loader will be sensitive to signals on any of the potential input sources. Not sure it programs the TX pin or the USART until it has measured the 0x7F pattern using a TIM input.

[Jim Seymour]

Posted on August 24, 2017 at 22:03

Thanks. We are beginning to suspect that the chip in question was

programmed with Read Out Protection Level 2 - which means the Boot

Loader is disabled.

So now I have a followup question: Can a Level 2 protected device be erased?

[Tesla DeLorean]

Posted on August 24, 2017 at 22:15

>>So now I have a followup question: Can a Level 2 protected device be erased?

I would expect so, provided your code is all running within the part, although there's clearly a greater potential to brick yourself. Something you'd likely wish to experiment with in the due-diligence phase.

[Jim Seymour]

Posted on August 24, 2017 at 22:49

Well, there's the problem.  It's not our code in the device right now - but I wanted to provide the option to overwrite it.

Based on experiments done with a ST-Link adapter and an STM32F030C8T6, setting the chip to Level 2 is a one-way trip.  (Which really surprises me).

[Tesla DeLorean]

Posted on August 25, 2017 at 01:01

>>

Which really surprises me

Assume the point of protection is to eliminate the vectors of attack.

>>

It's not our code in the device right now - but I wanted to provide the option to overwrite it.

I don't see that happening unless the loaded firmware provides a provision to update, or has a determinable weakness.

You initially mentioned the F103, don't recall that having multiple levels, and could be mass-erased and rewritten.

[Jim Seymour]

Posted on August 28, 2017 at 22:48

For those playing along at home, my problem was related to how my hardware behaved and the timing of the power cycle.  I was bringing the BOOT0 pin high and then powering up the STM32 - but it turned out that the STM32 was already powered up when I started my code - so powering it up did not activate the boot loader.  So I changed my code to force the power off and then wait for some time before asserting BOOT0.  Now, it appears to be working as expected...