STM32F051 bricked after low level programming of GPIO pins

[GenuineDeveloper]

I am using STM32F051R8T6 controller. I was initially using the standard peripheral library's inbuilt functions and structures to initialize the peripherals for eg. GPIO. Now, I want to optimize my code(size) by trying to directly write into the register for initializing my GPIO pins. But, to my surprise, after downloading the flash to the controller, it stopped working, as in the IDE could not communicate with the controller( unable to erase, or flash) any further. I tried using STLink Utility as well. Did I accidentally change any pin config that is supposed to be untouched for the normal operation of the controller? Is the device bricked? How can it be recovered?

Please find the initialization code below:

void Init_Gpio(void)
{
	RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
	RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOB, ENABLE);
	RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOC, ENABLE);
	RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOF, ENABLE);
 
	GPIOA -> MODER |= 0x000AF88B;
	GPIOB -> MODER |= 0xAAAA58AA;
	GPIOC -> MODER |= 0x0AAAAA00;
	GPIOF -> MODER |= 0x0000A100;
 
	GPIOA -> OTYPER |= 0;
	GPIOB -> OTYPER |= 0;
	GPIOC -> OTYPER |= 0;
	GPIOF -> OTYPER |= 0;
 
	GPIOA -> OSPEEDR |= 0x00200000;
	GPIOB -> OSPEEDR |= 0 ;
	GPIOC -> OSPEEDR |= 0 ;
	GPIOF -> OSPEEDR |= 0 ;
 
	GPIOA -> PUPDR |= 0x008A0440;
	GPIOB -> PUPDR |= 0x0000A415;
	GPIOC -> PUPDR |= 0x0AAAAA00;
	GPIOF -> PUPDR |= 0x00000400;
 
	GPIO_PinAFConfig(GPIOB,GPIO_PinSource6,GPIO_AF_1);
	GPIO_PinAFConfig(GPIOB,GPIO_PinSource7,GPIO_AF_1);
}

[Danish1]

If you want to program/debug by SWD, you need to leave the SWD pins untouched. These are PA13 and PA14. So the corresponding bits in GPIOA->MODER, OTYPER, OSPEEDR, PUPDR, AFRH must be left as is.

As to recovering it, do you have access to the BOOT0 pin? It is pin 60 of the 64-pin package. Having it at 0V at reset will cause your FLASH code to run, and immediately disable the SWD pins.

But if BOOT0 is high at reset then the ST-written bootloader should run, and PA13 and PA14 should be left able for you to debug and program.

Hope this helps,

Danish

[GenuineDeveloper]

I was aware about this that PA13 and PA14 should not be disturbed. Hence you can see that I have ORed GPIOA with the values( in which the last byte is 0). Therefore I believe that it should not have disturbed PA13 and PA14. Am I correct?

[Ozone]

> But if BOOT0 is high at reset then the ST-written bootloader should run, and PA13 and PA14 should be left able for you to debug and program.

Then fire up the ST-Link utility, and do a Flash mass erase.

Try several times if you don't get access the first time.

I agree with Danish - better never touch the debug pins.

[GenuineDeveloper]

I was aware about this that PA13 and PA14 should not be disturbed. Hence you can see that I have ORed GPIOA with the values( in which the last byte is 0). Therefore I believe that it should not have disturbed PA13 and PA14. Am I correct?

[Uwe Bonnes]

Does you program use deep sleep? Maybe it hangs there. Try to connect under reset.

Check also that the STM32 does not get hot. Getting hot is sign of having broken the chip.

[GenuineDeveloper]

No it does not have deep sleep. And it doesn't get hot. I had two chips which were working fine when I was using the SPL's inbuilt function. But both of them stopped responding after using the above code.

[Uwe Bonnes]

So try to connect under reset!