cancel
Showing results for 
Search instead for 
Did you mean: 

FIrmware faulty jumps into DFU mode while plugging into my PC.

Param sivan
Associate II

STM32L422kb

Hi,

I have created a USB sensor project through MX cube as FreeRtos based CDC device in FS mode. The sensor is detected as a com port in the device manager while I connect to the USB port in my PC. But sometimes it won't, It detected as a DFU(STM32 Bootloader) device under the USB section. It means the firmware jumps into the bootloader during powerup.

How to lock up the bootloader jumps? Is there anything I am missing in the configuration?

Boot0 pin is idle. (No external pull-up or Pulldown).

Thanks,

Param.

1 ACCEPTED SOLUTION

Accepted Solutions
Mike_ST
ST Employee

>> Shall I uncheck "nSWBoot0" to directly jump to the main flash memory?

As you don't have external Pull-Down on BOOT0, you have to use the option byte. So I recommend to uncheck it.

>> How to add these settings to the firmware?

You can either use the -ob option when programming your boards at production time:

STM32_Programmer_CLI.exe -c port=SWD -d "your firmware" -ob nSWBOOT0=0 nBOOT0=1

Or you can program it from the firmware itself using the FLASH HAL functions, and jump to your code after flashing.

View solution in original post

5 REPLIES 5
Mike_ST
ST Employee

>> Boot0 pin is idle. (No external pull-up or Pulldown).

Please configure nSWBOOT0 and nBOOT0/nBOOT1 option bytes with the STM32CubeProgrammer, these options should be available on L422.

0693W00000BaNlpQAF.pngThanks for the replay.

Currently, all checkboxes are activated.

Shall I uncheck "nSWBoot0" to directly jump to the main flash memeory?

How to add these settings to the firmware?

Mike_ST
ST Employee

>> Shall I uncheck "nSWBoot0" to directly jump to the main flash memory?

As you don't have external Pull-Down on BOOT0, you have to use the option byte. So I recommend to uncheck it.

>> How to add these settings to the firmware?

You can either use the -ob option when programming your boards at production time:

STM32_Programmer_CLI.exe -c port=SWD -d "your firmware" -ob nSWBOOT0=0 nBOOT0=1

Or you can program it from the firmware itself using the FLASH HAL functions, and jump to your code after flashing.

Thanks to @Mike_ST​ . It solved my issue 🙂

I am using the HAL flash function and fixed the bug.

void Write_OptionByte(void)
{
	// Reset nSWBoot0 = 0;
 
	OBInit.USERType = OB_USER_nSWBOOT0;
	OBInit.USERConfig = 0;
	OBInit.OptionType = OPTIONBYTE_USER; // of type FLASHEx_OB_Type
 
	/* Unlock the Flash to enable the flash control register access *************/
	if(HAL_FLASH_Unlock() == HAL_OK)
	{
		if(HAL_FLASH_OB_Unlock()== HAL_OK)
		{
			//if(HAL_FLASHEx_OBErase() == HAL_OK) {
				// program selected option byte
				HAL_FLASHEx_OBProgram(&OBInit); // result not checked as there is no recourse at this point
 
				if(HAL_FLASH_OB_Lock() == HAL_OK) {
					HAL_FLASH_Lock(); // again, no recourse					
				}
			//}
 
		}
	}
}

After I modified the firmware, sometimes the RDP bit corrupted and charged to FF. WHat could be the reason?

Is there any function to Erase the OB byte? need to erase before changing the value?