This post was last edited by shipeng on 2019-5-15 18:48 I recently used the USB_OTG_FS of STM32F429 to make a BOOTLOADER that can read files in the USB disk through USB (PA11, PA12) or update the APP through UART. Everything is normal for UART upgrade, but there is a small problem with USB upgrade: the upgrade process is smooth, but when it comes to jumping to APP, the chip first has no output or low output of the backlight driver IO (other IO states are unknown, suspected to be similar to the backlight driver IO). After waiting for a few seconds, the chip is reset, and it can enter the APP normally after reset. But I have to wait for several seconds before the reset. I don’t understand why. If it is a HardFault abnormal interrupt, my watchdog is not enabled, and there is no reason for the chip to reset? This problem cannot be simulated, because once the chip is reset, the emulator loses synchronization with the chip. I commented out the code section by section and found that if the "USBH_Process(&USB_OTG_Core, &USB_Host);" function and the loop it is in are commented out, the reset problem will not occur and the APP will jump normally. I would like an expert to help me solve this problem. U disk upgrade function: /* ************************************************************************************************************ * Function Name : Programing_From_Flie * Function Detail : Programing The Chip From a Flie * Paramater : None * Return Value : None ************************************************************************************************ */ void Programing_From_Flie(void) { static uint8_t page_buffer[4096]; #if defined BK180H const char object_path[]="0:BK180H.bin"; #elif defined BK300H const char object_path[]="0:BK300H.bin"; #elif defined U180 const char object_path[]="0:U180.bin"; #endif PrintMessage("Udisk Connected!"); =rgb(222, 240, 251)] SysTick_Init(); do { USBH_Process(&USB_OTG_Core, &USB_Host); } while (count_ms<8000 && (USB_Host.gState!=HOST_CLASS || USBH_MSC_BOTXferParam.MSC State!=0x05)); SysTick->CTRL=0x00; //Stop Counter char string_buf[24]="Scanning for "; for (u8 i=13;i<24;i++)string_buf=object_path[i-11]; PrintMessage(string_buf); result = f_mount(&fs,"0:",1); /* Mount a logical drive */ if (result != FR_OK) { PrintMessage("Mounting Failed!"); return; } result = f_open(&file, object_path, FA_OPEN_EXISTING | FA_READ); if (result == FR_OK) { if (file.fsize==0 || file.fsize>0x1F8000) { PrintMessage("File Size Error!"); goto close_file_exit; } if (FLASH_If_GetWriteProtectionStatus() == 0) { /* Disable the write protection */ if (FLASH_If_DisableWriteProtection()==1) { PrintMessage("Write Protection disabled!"); } else { PrintMessage("Error: Flash write unprotection failed!"); goto close_file_exit; } } PrintMessage(" Chip Erassing"); FLASH_If_Erase(APPLICATION_ADDRESS,file.fsize); PrintMessage("Chip Programming"); uint32_t flashdestination = APPLICATION_ADDRESS; uint32_t packets_max = file.fsize/4096+(file.fsize%4096==0?0:1); for (uint32_t packets_readed =0;packets_readedCTRL=0x00; //Stop Counter //Jump to APP code/* Test if user code is programmed starting from address "APPLICATION_ADDRESS" */ if (((*(__IO uint32_t*)APPLICATION_ADDRESS) & 0x2FFE0000 ) == 0x20000000) { __asm("CPSID I");__asm("CPSID F"); USBH_DeInit(&USB_OTG_Core,&USB_Host); /* Jump to user application */ JumpAddress = *(__IO uint32_t*) (APPLICATION_ADDRESS + 4); Jump_To_Application = (pFunction) JumpAddress; /* Initialize user application's Stack Pointer */ __set_PSP(*(__IO uint32_t*) APPLICATION_ADDRESS); __set_CONTROL(0); __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS); Jump_To_Application(); //APP jump code ends} } else { PrintMessage("Error File Opening!"); } close_file_exit: f_close(&file); }
In addition, I would like to explain that the USB function is not used in the APP and I also turned off the interrupt before jumping, but for some reason the exception still occurs.
Yay, the problem is solved! The solution is to turn off the USB peripheral clock before jumping to the APP: RCC_AHB2PeriphClockCmd(RCC_AHB2Periph_OTG_FS, DISABLE); then there will be no jump abnormality problem. I suspect the reason may be that after the USB interrupt is enabled in the BOOTLOADER, the USB function is not used when jumping to the APP, so the USB interrupt entry is not set, resulting in interrupt overflow. To be on the safe side, all enabled peripherals should be turned off before jumping to the APP.