Ensure a pin is low while in bootloader

[4lch]

Hi and thanks in advance !

My application uses a STM32G0B0 to control an LED driver through PWM among other things (pin (26)-PB14).

The device can receive commands and I have added an option to jump to bootloader through a special command to perform firmware updates through USB. This works well, however, the pin I use to control the PWM LED driver remains high while in the bootloader, which could cause the LED board to heat up too much.

I have tried to stop the timer and configure the pin low before jumping, and it works to pull the pin low right until the jump is actually made.

A pull-down resistor soldered between the PWM pin and GND did not change this behaviour either.

Could the bootloader be forcing this specific high ? What other options could there be to make sure it remains low while in the bootloader ?

Here is the current bootloader jump code, stripped of my attempts to turn off the pin before jumping :

void JumpToBootLoader() {

	void (*SysMemBootJump)(void);

	HAL_DeInit();

	/* Disable all interrupts */
	__disable_irq();

	/* Disable Systick timer */
	SysTick->CTRL = 0;

	/* Set the clock to the default state */
	HAL_RCC_DeInit();

	/* Clear Interrupt Enable Register & Interrupt Pending Register */
	for (uint32_t i=0;i<sizeof(NVIC->ICER);i++)
	{
		NVIC->ICER[i]=0xFFFFFFFF;
		NVIC->ICPR[i]=0xFFFFFFFF;
	}

	/* Re-enable all interrupts */
	__enable_irq();

	/* /!\ THIS LINE IS REQUIRED TO REMAP MEMORY BY HAND BEFORE JUMPING /!\ */
	SYSCFG->CFGR1 = 0x01;

	SysMemBootJump = (void (*)(void))(*((uint32_t *)(0x1FFF0000  + 4)));
	__set_MSP(*(__IO uint32_t *)0x1FFF0000);

	SysMemBootJump();
}

Thanks in advance !

[gbm]

The explanation of boot mode behavior may be found in AN2606. Please Read The Fine Document.

[4lch]

Thanks a lot for pointing me to this document !

Indeed it mentions that the pin is used as SPI2 MISO in push-pull, pull-down mode, but set to 3.3V "on the bootloader start-up after SPI initialization as soon as the bit DMATx enable on SPI CR2 register is set to 0x1"

Seems like dead-end with this current pin, I will look into moving it to another one that is not used during the bootloader. I assume that pins not used specifically during the bootloader should be floating or hopefully weak enough that an external pull-down resistor should guarantee that it is low ?

Thanks again !

[gbm · Accepted solution]

The default pin configuration for every STM32 is specified in RefMan - GPIO - Registers; see the reset values of MODER and PUPDR. One important thing which is not explicitly mentioned in this section of RefMan is the default behavior of CC and DBCC pins in MCUs equipped with UCPD peripheral (like G0B). To keep it short: all the CC pins may have 5k1 pulldowns active after reset, but this does not interfere with your app.

[MM..1]

As you can see this pin is used not unused, then for bootloader using you need plan pins in app or create own custom bootloader. Too on some ST bootloaders is initialized pins not listed in AN2606 ...

[waclawek.jan]

In many cases, it's better to write your own bootloader over which you have full control, rather than trying to work around the peculiarities (not always well documented) of the default one.

JW

[4lch]

Thanks a lot, this is very useful as someone still figuring out a lot of things ! This is a great point about the UCPD peripheral, the application does not use it, only the USB data lines and the CC lines being pulled down would not be an issue indeed.

The option to write a custom bootloader also seems interesting, since skipping the activation of SPI2 should prevent this behaviour as well, probably a solid option to avoid having to modify the current board layout.

Thanks again !

[4lch]

Thanks a lot ! This is leading to an interesting rabbit hole as someone who's still very much a beginner :)

The custom bootloader option seems great indeed. If I understand it correctly, the actual bootloader lives in ROM, so a custom one would be in flash and for example expose only the interesting interfaces (USB DFU in my case) to upload a new firmware ?

Thanks again for your help !

[4lch]

Thanks a lot, this is not an option I had in mind !  I will look into that. I only need to setup USB DFU for firmware updates during the bootloader so hopefully it should not be too bad !