Unable to enter system bootloader STM32C071FBP6N

[NotThomasEdison]

Hi,

As per title I am unable to enter the System Memory bootloader when using the STM32C071FBP6N. Any assistance would be greatly appreciated.

Following the notes in AN2606, i have configured pattern 11 (line 2) using the CubeProgrammer but when completing the reset with the Boot0 pin high it does not enter the bootloader mode and can tell this because my user application runs immediately after the reset occurs.

I have been able to jump to the bootloader through my own firmware where I initialize the HAL and GPIOs and then check the status of the boot0 or other pins then manually change the PC and SP but wish to avoid this method as this should not be necessary.

-------

I have followed the steps below:

1. Using a ST-Link I have successfully changed the option bits nBOOT_SEL=0; nBOOT1=1; nBOOT1=1; BOOT_LOCK=0 using the CubeProgrammer and have also flashed a basic UART output program which outputs to USART2 the whether the PA14/BOOT0/PA15 is high or low.

2. disconnect the ST-Link (since it interferes with the BOOT0 pin of this chip)

3. Set the BOOT0 pin high and then set nRST low then high

At this point i still see my application code running and output to the UART saying the PA14/BOOT0/PA15 is high

note: I am using minicom to read the UART and I have 'read' the option bit configurations to ensure they are properly saved on the device; Hardware-wise I am using a 10k Ohm pulldown resistor for the BOOT0 pin

[NotThomasEdison]

“And do you keep the BOOT0 pin low while nRST goes high? That is where it matters.”

The documentation says the BOOT0 pin should be high to enter the bootloader mode as per pattern 11 row 2.

But I have tested it with the BOOT0 remaining a constant LOW and HIGH during on the rising edge of nRST but neither automatically entered the system memory address from what I could tell and immediately ran my application code. 

[EThom.3]

Yes, BOOT0 should of course be kept high, not low. Sorry. Typo. I was tired.

But that is indeed weird behaviour you are describing. The only thing I can think of is to verify the signals with an oscilloscope, and to re-check (again) that BOOT_LOCK, nBoot1 and nBOOT0_SEL really have the expected values. It shouldn't matter whether the signals come from mechanical buttons or another chip.

I have never experienced this issue myself.