STM32G070 entering system bootloader mode with the boot pin.

[Jonathan Harding]

I am struggling to get an STM32G070RBT6 into bootload mode with the boot pin.

Using ST-Link utility I have set nBOOT1 = 1, NBOOT_SEL = 0 and left nBOOT0 = 1.

If I have understood the datasheet correctly this should allow me to enter bootload mode by holding BOOT0 pin high and toggling the reset pin. However the uC jumps straight into the main code.

I have disabled serial wire debug as it share BOOT0 pin, but that didn't help.

Just as a test I have managed to get the device into bootload mode by setting nBOOT1 = 1, NBOOT_SEL = 1 and nBOOT0 = 0 using ST-Link Utility. I then successfully confirmed I can bootload my code. However this mode of entrance defeats the whole point!

Can anybody see what I am doing wrong or share their success with this part

Thanks Jonathan

[KnarfB]

Are you using a pull-up/down R for nBOOT0?

And disconnect ST-LINK for testing because PA14 might interfere?

Works here as expected using a Nucleo-STM32G071RB board.

hth

KnarfB

[Piranha]

Does ST-Link Utility support G0 series at all?

Just for information:

https://community.st.com/s/question/0D53W00001fzDxdSAE/did-st-break-systick-in-the-last-update-it-used-to-work-now-it-crashes-because-i-think-the-interrupt-vector-is-not-set-is-this-one-of-those-known-errors-how-do-i-fix-it

[Jonathan Harding]

Thanks for the replies.

BOOT0 has a pull down for normal operation, however whilst I've been testing it has been actively driven.

I have tried without the ST-Link connected.

Just for a sanity check, I can say 100% the CPU resets on toggle of the reset pin and I have confirmed BOOT0 pin (pin 46 in my case) is being correctly controlled.

Current sequence, BOOT pin high, NRST pin low, NRST pin high.

Then the program memory code runs.

Is it possible that the uC is jumping into system memory but then jumping straight back out for some reason?

Jonathan

[Jonathan Harding]

I've done some more testing and found some interesting results.

Following an option bytes write it seems I can enter the boot loader via the BOOT0 pin method. I have proven this by erasing the device, then when reset with BOOT0pin low the bootloader fails, but when reset with BOOT0pin is high I can successfully boot load.

HOWEVER once the program memory has been entered it seems impossible to enter the bootloader mode again using BOOT0pin method. To enter bootload mode again the option bytes need writing again, whilst not allowing the uC to enter the main program memory.

I suspect this is to do with the FLASH_ACR register EMPTY bit. I am guessing here but suspect this flag is read in the bootloader and if it is 0 (main flash area programmed) it jumps to the main code NOT allowing bootloading as I would like.

Would someone please confirm my finding.

At this stage I'm assuming this is going to require some software to set the FLASH_ACR register EMPTY bit when I want to bootload and then do a software reset or something along those lines.

Jonathan

[RHelv.1]

@Jonathan Harding Was there any resolution to this issue? I'm having the exact same issue using the STM32G071.

Thanks,

Rob

[Jonathan Harding]

I'm afraid not (not with the boot pin anyway), I seem to remember the boot pin only works on a power cycle reliably.

I ended up using a different GPIO pin, checking it on start up of my main code and jumping to the bootloader.

This code seems to work reliably to jump into the bootloader:

static void

JumpToBootloader (void)

{

void

(*SysMemBootJump) (void);

volatile uint32_t addr = 0x1FFF0000;

HAL_RCC_DeInit ();

SysTick->CTRL = 0;

SysTick->LOAD = 0;

SysTick->VAL = 0;

__disable_irq ();

__HAL_RCC_SYSCFG_CLK_ENABLE();           //make sure syscfg clocked

__DSB ();

__HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH(); //remap system memory to address 0x0000000

__DSB ();

__ISB ();

SCB->VTOR = 0;                           //set vector table offset to 0

FLASH->ACR |= FLASH_ACR_PROGEMPTY;

SysMemBootJump = (void

(*) (void)) (*((uint32_t*) (addr + 4)));

__set_MSP (*(uint32_t*) addr);

SysMemBootJump ();

}

[jbreaper]

I had a similar issue using a Nucleo-g070RB, I found that disabling the STLINK and debugger (removing the jumpers on CM4) solved the problem and let me enter the bootloader using NRST and BOOT0. Not sure if this'll help you, but I thought I'd way in with what helped me

[Stefano Ugolini]

I'm having the same issue with the same MCU family:
https://community.st.com/t5/stm32-mcus-products/bootloader-activation-stm32g0c1/m-p/719761#M260755

Can someone from ST have a look into it?

[RHelv.1]

You have to make sure the MCU isn't getting backpowered via another pin. Our problem was that although nRST was low, we had high voltage at various other pins (from sinking configuration LEDs), so the MCU was is some undefined state. I recommend probing every MCU pin and seeing which pins are still high when nRST is low, and then figure out how to remove voltage from these pins. If the only pin that has voltage is VDD, then you'll be fine.