STM32F107 SD CARD BOOTLOADER

[giovani]

Posted on August 24, 2015 at 15:41

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, Giovani

[Tesla DeLorean]

Posted on August 24, 2015 at 16:35

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.

[giovani]

Posted on August 24, 2015 at 16:51

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. Thanks

[giovani]

Posted on August 28, 2015 at 17:00

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.

[giovani]

Posted on August 28, 2015 at 17:11

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.

[Tesla DeLorean]

Posted on August 28, 2015 at 17:59

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.

[Tesla DeLorean]

Posted on August 28, 2015 at 18:03

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.

[giovani]

Posted on February 16, 2016 at 20:06

Hello!

I have a problem

again with

the custom

bootloader

, sometimes

it

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

[Tesla DeLorean]

Posted on February 16, 2016 at 21:21

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.