2015-08-24 06:41 AM
Good morning!
I was trying to develop a bootloader from sd card, writing two programs in the flash pages first is my own bootloader that verify if is there any .bin files for update the other flash region where my other app is running, all works fine except for the time that is updated the flash, flash write routine works perfect but when Jump_To_Application () is called my app hangs and I need to power down the board and turn on again,then all works fine. if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000) { /* Jump to user application */ JumpAddress = *(__IO uint32_t*) (ApplicationAddress + 4); Jump_To_Application = (pFunction) JumpAddress; App_ptr = (uint8_t*)Jump_To_Application; if( (*App_ptr != 0xFF) && (App_ptr) ) { /* Initialise user application's Stack Pointer */ //__set_MSP(*(__IO uint32_t*) ApplicationAddress); *((unsigned long *)0x2000FFF0) = ApplicationAddress; Jump_To_Application(); } } I want your help if anyone knows what kind of problem could be this, I want to update the flash and the new program run after the flash is updated. Flash regions: Bootloader 0x8000000-0x8009FFF My App 0x800A000-0x8040000 Thanks, Giovani2015-08-24 07:35 AM
Do you have any interrupts in the boot loader? You need to tear that all down and do a clear handoff to the application. You can't leave random interrupts enabled. SysTick, TIM, DMA, SDIO, etc. If using an RTOS watch for user/system context issues.
Instrument your code, have a proper Hard Fault Handler, and step into the application code across this control transfer code to understand what's happening.2015-08-24 07:51 AM
Clive!
I will verify if is there some interrupt enabled, but I don't understand why when doesn't exist none .bin files in sd card the first application running on flash address 0x8000000 jump to another applicattion with no problem, just when write flash this occurs the other application doesn't run. Thanks2015-08-28 08:00 AM
Hello!
I tried the source below but ocurr the same errors. ..... FlashFirmware(); __disable_irq(); ...... /* Test if user code is programmed starting from address ''ApplicationAddress'' */ if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000) { /* Jump to user application */ JumpAddress = *(__IO uint32_t*) (ApplicationAddress + 4); Jump_To_Application = (pFunction) JumpAddress; App_ptr = (uint8_t*)Jump_To_Application; if( (*App_ptr != 0xFF) && (App_ptr) ) { /* Initialise user application's Stack Pointer */ *((unsigned long *)0x2000FFF0) = ApplicationAddress; Jump_To_Application(); } } I don't know if the error is in the custom bootloader firmware or in app firmware, but the error just happened when the app flash region is updated. If the board is powered down e powered on again all works fine.2015-08-28 08:11 AM
Hello!
I tried the source below but ocurr the same errors. ..... FlashFirmware(); __disable_irq(); ...... /* Test if user code is programmed starting from address ''ApplicationAddress'' */ if (((*(__IO uint32_t*)ApplicationAddress) & 0x2FFE0000 ) == 0x20000000) { /* Jump to user application */ JumpAddress = *(__IO uint32_t*) (ApplicationAddress + 4); Jump_To_Application = (pFunction) JumpAddress; App_ptr = (uint8_t*)Jump_To_Application; if( (*App_ptr != 0xFF) && (App_ptr) ) { /* Initialise user application's Stack Pointer */ *((unsigned long *)0x2000FFF0) = ApplicationAddress; Jump_To_Application(); } } I don't know if the error is in the custom bootloader firmware or in app firmware, but the error just happened when the app flash region is updated. If the board is powered down e powered on again all works fine.2015-08-28 08:59 AM
I don't know if the error is in the custom bootloader firmware or in app firmware, but the error just happened when the app flash region is updated.
Ok, so you'll have to instrument and debug your code/system, and figure that out, I don't have any magic insight into what you're doing wrong. The F1 doesn't have any caching. A decent debugger should allow you to step through this code, and into the application and get some awareness about what's happening. Proper Hard Fault handlers in both the loader and app should provide information if the code ends up there.INSTRUMENT - Have a USART configured and print out information about where you are in the code, and the state of memory and register related to the FLASH and FLASH Controller. GPIO and LED states can also be used.Dump out or checksum/crc the memory with your code. Make sure the app code you're jumping too is aware the system isn't in a reset state (ie clocks / plls are running, peripherals/pins are enabled). The App needs to set the Vector Table (SCB->VTOR) to it's own address.2015-08-28 09:03 AM
Understand that __disable_irq(); is a cop out, it's not the same as you turning off, and tearing down the interrupts you have set up. Does the app have a matching __enable_irq() ? What happens then? If the app doesn't have handlers, it's going to jam up in a while(1); loop in some default handler.
2016-02-16 11:06 AM
Hello!
I have a problem
again with
the custom
bootloader
, sometimesit
correctly initialize
other times it
remains in a
resetting
loop.
Another situation
is
in the application
firmware is
enabled
IWDG
if he
triggered or
the reset button
is pressed,
it is the same
situation
of being
in a
reset
loop.
If anyone can
help me
I will be
grateful.
Thank you,
Giovani
2016-02-16 12:21 PM
You'd want to identify all the while() loops that you might get stuck in, or spend an unusual amount of time in. Like things waiting for oscillators to come ready, or PLLs to lock.
Try without the IWDG, and restart until you get a lock condition, and break out in the debugger to see where you are.Output state via a character on the USART, or with GPIO pins, send marker characters so you can see the reset, and when it enters/exits while() loops that could lock up.Profile the failing reset loops with theses outputs to see the failure sequence/pattern. Fine tune the detail as you focus in on the offending code.