DFU mode STM32H7B3

[MMarco]

Hello,

we are facing some problem entering DFU mode from application code on our custom boards equipped with STM32H7B3 with bootloader release 0x92. 

On contrary, everything works fine with same board equipped with STM32H7B3 bootloader release 0x91.

Beside the notes on AN2606 related to bootloader history, can someone from ST point out if are there any other changes on bootloader that can cause this strange behaviour?

Thanks,

Regards,

[mƎALLEm]

Hello @MMarco and welcome to the ST community,

What do you mean by "this strange behaviour?" 

Could you please describe in details what is the problem you are facing?

[MMarco]

Hello @mƎALLEm,

basically with STM32H7B bootloader 0x91 we are able to jump from our running application to bootloader and then flash new firmware with DFU mode.

Same boards but with STM32H7B bootloader 0x92 we are not able to jump from our running application to bootloader.

I would add that we even tried swapping of Boot Address Option Bytes setting BOOT_CM7_ADD0 to 0x1ff0 and BOOT_CM7_ADD1 to 0x8000:

STM32H7B bootloader 0x91 run correctly to DFU Mode

STM32H7B bootloader 0x92 doesn't run to DFU Mode 

Thanks,

Regards,

[mƎALLEm]

Ok, thank you for the details. I will report it internally for more investigation. We will get back to you as soon we have any feedback. Internal ticket 207807.

[mƎALLEm]

Hello @MMarco ,

Our development team thoroughly checked a simple application from their side, and it is running correctly, they were able to jump to the bootloader.
To assist you further, could you please provide more details about the behavior of your application ? specifically:

1- Is the application crashing or showing any error messages when attempting to jump to bootloader ?

2-  What is the content of the PC of CPU registers ?

[MMarco]

Hello @mƎALLEm,

STM32H7B bootloader 0x91 application jumps correctely to bootloader. USB port is enumerated as DFU.

STM32H7B bootloader 0x92 after jump USB port is not enumerated as DFU. It looks like is stuck somewhere into bootloader.

Registers contents after unsuccessful jump:

General Registers General Purpose and FPU Register Group

r0 0x6200e2 (Hex)
r1 0x800000 (Hex)
r2 0x2 (Hex)
r3 0x0 (Hex)
r4 0x240004cc (Hex)
r5 0x58024538 (Hex)
r6 0x200 (Hex)
r7 0x40013000 (Hex)
r8 0x40003800 (Hex)
r9 0x40003c00 (Hex)
r10 0x40013400 (Hex)
r11 0x40004800 (Hex)
r12 0x80000000 (Hex)
sp 0x24003f78 (Hex)
lr 0x1ff0cd41 (Hex)
pc 0x1ff0cbee (Hex)
xpsr 0x1000000 (Hex)
d0 0x4140000003f940ac (Hex)
d1 0x4348000043470000 (Hex)
d2 0x0 (Hex)
d3 0x0 (Hex)
d4 0x0 (Hex)
d5 0x4600000000000000 (Hex)
d6 0x4df4240000000000 (Hex)
d7 0xf42400040000000 (Hex)
d8 0x0 (Hex)
d9 0x0 (Hex)
d10 0x0 (Hex)
d11 0x0 (Hex)
d12 0x0 (Hex)
d13 0x0 (Hex)
d14 0x0 (Hex)
d15 0xffffffff00000000 (Hex)
fpscr 0x2000010 (Hex)
msp 0x24003f78 (Hex)
psp 0x0 (Hex)
primask 0x0 (Hex)
basepri 0x0 (Hex)
faultmask 0x0 (Hex)
control 0x4 (Hex)
s0 0x3f940ac (Hex)
s1 0x41400000 (Hex)
s2 0x43470000 (Hex)
s3 0x43480000 (Hex)
s4 0x0 (Hex)
s5 0x0 (Hex)
s6 0x0 (Hex)
s7 0x0 (Hex)
s8 0x0 (Hex)
s9 0x0 (Hex)
s10 0x0 (Hex)
s11 0x46000000 (Hex)
s12 0x0 (Hex)
s13 0x4df42400 (Hex)
s14 0x40000000 (Hex)
s15 0xf424000 (Hex)
s16 0x0 (Hex)
s17 0x0 (Hex)
s18 0x0 (Hex)
s19 0
s20 0
s21 0
s22 0
s23 0
s24 0
s25 0
s26 0
s27 0
s28 0
s29 0

Would you please share the simple code used by development team to give it a try?

Thanks,

Regards,

[mƎALLEm]

Hello,

Answer from our Bootloader team:

The program counter is at the address 0x1FF0CBBE which is within the loop of the bootloader to select the protocol used.
So the question is: does the bootloader from your side boots correctly without the jump application when using the USB interface, but fails to connect when the JUMP application is used?
In attachment, the binary file of our application we used for the jump. Please get back to us wit the result.

[MMarco]

Hi @mƎALLEm 

Let me try to elaborate more about our project.

We have several boards build with mixed STM32H7B processor, some with bootloader 0x91 some with bootloader 0x92, other than that same BOM, all boards tested and fully working. We actually use USB as debug interface implemented as Virtual Com Port in our FreeRTOS application.

Jump to bootloader is performed with the below code:

#define BOOT_ADDR 0x1FF0A000 // my MCU boot code base address

#define MCU_IRQS 70u // no. of NVIC IRQ inputs

struct boot_vectable_

{

uint32_t Initial_SP;

void (*Reset_Handler)(void);

};

#define BOOTVTAB ((struct boot_vectable_ *) BOOT_ADDR)



void JumpToBootloader (void){



cliPrint("Entering DFU mode\r\n");

cliPrint(">");

// allow delay for test program to close com port

HAL_Delay(2000);



// remove USB cdc

MX_USB_DEVICE_DeInit();



// give some time to Windows to understand that CDC in not here any more

HAL_Delay(2000);



/* Set the clock to the default state */

HAL_RCC_DeInit();



__HAL_RCC_GPIOA_CLK_DISABLE();



RCC_OscInitTypeDef RCC_OscInitStruct = {0};

RCC_ClkInitTypeDef RCC_ClkInitStruct = {0};



/*AXI clock gating */

RCC->CKGAENR = 0xFFFFFFFF;



/** Initializes the RCC Oscillators according to the specified parameters

* in the RCC_OscInitTypeDef structure.

*/

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI48|RCC_OSCILLATORTYPE_HSI;

RCC_OscInitStruct.HSIState = RCC_HSI_DIV1;

RCC_OscInitStruct.HSICalibrationValue = 64;

RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

{

Error_Handler();

}



/** Initializes the CPU, AHB and APB buses clocks

*/

RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_HCLK|RCC_CLOCKTYPE_SYSCLK

|RCC_CLOCKTYPE_PCLK1|RCC_CLOCKTYPE_PCLK2

|RCC_CLOCKTYPE_D3PCLK1|RCC_CLOCKTYPE_D1PCLK1;

RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_HSI;

RCC_ClkInitStruct.SYSCLKDivider = RCC_SYSCLK_DIV1;

RCC_ClkInitStruct.AHBCLKDivider = RCC_HCLK_DIV1;

RCC_ClkInitStruct.APB3CLKDivider = RCC_APB3_DIV1;

RCC_ClkInitStruct.APB1CLKDivider = RCC_APB1_DIV1;

RCC_ClkInitStruct.APB2CLKDivider = RCC_APB2_DIV1;

RCC_ClkInitStruct.APB4CLKDivider = RCC_APB4_DIV1;



if (HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_3) != HAL_OK)

{

Error_Handler();

}



// unlock Flash

HAL_FLASH_Unlock();



/* Disable all interrupts */

__disable_irq();



/* Disable Systick timer */

SysTick->CTRL = 0;



/* Clear Interrupt Enable Register & Interrupt Pending Register */

for (uint8_t i = 0; i < (sizeof(NVIC->ICER) / sizeof(*NVIC->ICER)); i++)

{

NVIC->ICER[i]=0xFFFFFFFF;

NVIC->ICPR[i]=0xFFFFFFFF;

}



/* Re-enable all interrupts */

__enable_irq();



// Set the MSP and other registers

__set_MSP(BOOTVTAB->Initial_SP);



__set_PSP(0x00);

__set_PRIMASK(0x00);

__set_CONTROL(0x00);



// Jump to app firmware

BOOTVTAB->Reset_Handler();



while(1)

{



}

}

With STM32H7B3 bootloader 0x91 we can see disconnection of USB as Virtual Com port and connection as USB DFU in FS Mode Device.

With STM32H7B3 bootloader 0x92 we can see disconnection of USB as Virtual Com port but USB is not enumerated as DFU in FS Mode Device.

Step by step run indicates that STM32H7B3 btl 0x92 is actually jumped into bootloader but for whatever reason is stuck somewhere maybe trying to use other interfaces for firmware update.

Another bit to add is that if we swap Boot address Option bytes bootloader 0x91 is working and USB is connected as DFU in FS Mode Device. Bootloader 0x92 is not.

Finally with the code provided by Bootloader team, both STM32H7 0x91 and 0x92 are not connected as DFU in FS Mode Device.

Not knowing bootloader application code we are currently guessing that for some reason is stuck in one of the other peripheral that can be used to update firmware such as SPI or i2C.

Actually DFU is the last one to be used in the flow chart provided by AN2606.

Is there any hardware limitation or constrain in the connection of peripheral that can stuck bootloader?

Thanks,

Regards,

[mƎALLEm]

Hello,

First, please kindly use </> button to share a code. See this post. I've edited your post.

Second, thank you for the sharing. One thing that I didn't catch in this statement:

---

@MMarco wrote:

With STM32H7B3 bootloader 0x91 we can see disconnection of USB as Virtual Com port and connection as USB DFU in FS Mode Device.

With STM32H7B3 bootloader 0x92 we can see disconnection of USB as Virtual Com port but USB is not enumerated as DFU in FS Mode Device.

---

What do you mean by "USB Virtual comport" here in the bootloader context. What it is used for? could you please give more details?

[MMarco]

Hi @mƎALLEm,

sorry for not being clear.

Virtual com port is used by our FreeRTOS application as debug/command interface not in bootloader environment.

Thanks,

Regards,