cancel
Showing results for 
Search instead for 
Did you mean: 

USB DFU on STM32F407IG not recognized by Windows 10

Hi,

I use the following code to jump to the bootloader:

typedef void (*pFunction)(void); /*!< Function pointer definition */

#define SYSMEM_ADDRESS (uint32_t)0x1FFF0000

void Bootloader_JumpToSysMem(void)

{

   uint32_t JumpAddress = *(__IO uint32_t*)(SYSMEM_ADDRESS + 4);

   pFunction Jump       = (pFunction)JumpAddress;

   HAL_RCC_DeInit();

   HAL_DeInit();

   SysTick->CTRL = 0;

   SysTick->LOAD = 0;

   SysTick->VAL = 0;

   __HAL_RCC_SYSCFG_CLK_ENABLE();

   __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();

   __set_MSP(*(__IO uint32_t*)SYSMEM_ADDRESS);

   Jump();

   while(1)

       ;

}

int main(void)

{

   HAL_Init();

   SystemClock_Config();

   Bootloader_JumpToSysMem();   

}

Notes:

  1. The app HAL-based skeleton is generated by the latest STM32CubeMX separatelly for STM32F411CE and STM32F407IG
  2. The code works FINE on STM32F411CE (W10 recognizes the USB and I am able to upload the code through STM32Programmer)
  3. The code fails when I use STM32F407IG (W10 does NOT recognize the USB device)
  4. Same W10 PC used in both cases
  5. PA11/PA12 in both cases are connected the same way (no external D+ pull-up used but the voltmeter shows that that D+ is pull-ed up - probably internally)
  6. I CANNOT set boot0/boot1 pins to test the USB DFU functionality without jumping to the bootloader from my app (these pins are not available to me)
  7. 25MHz crystal is used in the case of STM32F407

If you could share any tips why the STM32F411 may behave differently than STM32F407 in this case.

7 REPLIES 7
TDK
Guru

If you put Bootloader_JumpToSysMem() as the first function in main(), does the DFU bootloader get recognized correctly? If so, you need to deinitialize some stuff before jumping.

If you feel a post has answered your question, please click "Accept as Solution".

Could you please clarify?

As I wrote it works fine on STM32F411. I believe I deinitialized everything.

TDK
Guru
int main(void)
{
  Bootloader_JumpToSysMem();   
}

Try this:

If you feel a post has answered your question, please click "Accept as Solution".

Got it.

You want to verify if in case of the STM32F407 (because STM32F411 works fine so this is very specific to STM32F407) something is NOT deinitialized.

I will try it.

Unfortunately it did NOT help.

Maybe the problem is caused by the deinitialization code...

I also simplified the Bootloader_JumpToSysMem():

void Bootloader_JumpToSysMem(void)

{

   uint32_t JumpAddress = *(__IO uint32_t*)(SYSMEM_ADDRESS + 4);

   pFunction Jump       = (pFunction)JumpAddress;

//   HAL_RCC_DeInit();

//   HAL_DeInit();

//   SysTick->CTRL = 0;

//   SysTick->LOAD = 0;

//   SysTick->VAL = 0;

   // __HAL_RCC_SYSCFG_CLK_ENABLE();

   // __HAL_SYSCFG_REMAPMEMORY_SYSTEMFLASH();

   __set_MSP(*(__IO uint32_t*)SYSMEM_ADDRESS);

   Jump();

   while(1)

       ;

}

And also no help.

Hi,

I gave up the idea of jumping to the bootloader on this STM32F407 board.

Actually it's EvoPrimer, an old and decent piece of hardware, unfortunately somewhat constrained if it comes to using build-in bootloader or external SWD-based programmer (no boot pins exposed to the user, no SWD pins).

I decided to craft my own bootloader compatible with STM32Programmer and I did it yesterday (now I am able to upload the code to the SRAM (and run it) using UART6 - the only UART available to the user).

I do use the HSE (just to test the HSE as the USB bootloader leverages it and one may think it fails).

So I am done from my use case point of view.