Jump to application code STM32F072

[PBaie.1]

I have created a bootloader and application.  My bootloader appears to launch my application successfully; however, the interrupts are not functioning in the application.  

I used memcpy to copy the vector table into RAM. Below shows the results of the memcpy command.

Below is the code I use to copy the vector table and hopefully start to use the new RAM based vector table.

FLASH_VECTOR_ADDRESS = 0x08003000

VECTOR_TABLE_SIZE = 48

void copy_to_ram_vector_table(uint32_t *destination)
{

__disable_irq();

// Source address in flash (FLASH_VECTOR_ADDRESS)
uint32_t *source = (uint32_t *)FLASH_VECTOR_ADDRESS;

// Number of uint32_t values to copy
size_t num_elements = VECTOR_TABLE_SIZE;

// Use memcpy to copy the data
memcpy(destination, source, num_elements * RAM_VECTOR_DATA_SIZE);

__HAL_RCC_SYSCFG_CLK_ENABLE();
__HAL_SYSCFG_REMAPMEMORY_SRAM();

__enable_irq();
}

I have been able to verify that my main loop is running, but none of the interrupts are firing.  I have also verified that I successfully copied the vector table to RAM (address 0x20000000).  I used a scatter file to reserve a memory locations 0x20000000 - 0x200000BF are reserved for the vector table.

Any assistance would be greatly appreciated.

[Tesla DeLorean]

Have a workable Hard Fault Handler, and serial output working on the Loader side. Similarly Hard Fault and Error Handlers on the Application side.

Step thru the control transfer code, perhaps outputting to a USART or GPIO so you can determine.

Make sure you don't have interrupts firing, like SysTick, into code that's not yet initialized or expecting to be called.

[PBaie.1]

Hello,

I was able to debug the application after the transition.  I originally had some errors and ended up in the Hard Fault handler.  Once I was able to correct that the fault interrupt handler isn't reached any longer.

Could you please provide a bit more information on stepping through transfer code?  I am not sure what to look at here.

Yes, I believe I have the interrupts disabled, but is there a way to confirm they are not active/disabled?

[Tesla DeLorean]

Keil lets you source level debug either the loader or the application. You can still step the code and seem the disassembly of what's executing.

Breakpoint your control transfer point in the loader, where you're about to call the Reset_Handler of the app. Single step in the debugger, confirm you are in the code of the application. You can keep stepping, review the peripheral and core registers. Review your startup.s code.

Similarly if the loader transfers control successfully, move over to debugging the Application, perhaps uncheck the "run to main()" option so you can see the arrival in the Apps Reset_Handler(), follow code execution from there, or break-point deeper into the application. Check the peripheral and core state from there

[TDK]

> I have been able to verify that my main loop is running, but none of the interrupts are firing.

If interrupts aren't firing at all, as opposed to going into hard fault, then they're not configured right. You might also have a vector table issue but it's not the immediate one. Either they're globally disabled, or they haven't been set up properly. Check relevant bits in the peripherals and NVIC, and/or show relevant code.

Could also just be misinterpreting things. How are you verifying they aren't firing?

[Pavel A.]

> I used memcpy to copy the vector table into RAM

Good. Now remap the RAM to address 0. (explained in the forum several times, please search).

[PBaie.1]

I believe that is what this function is doing correct?

__HAL_SYSCFG_REMAPMEMORY_SRAM();

My understanding is that this function triggers the RAM to be remapped to 0x0 so it can be used as the new vector table location instead of the flash which was initially mapped at 0x00.  If there is a different method that should be used please let me know.  I have reviewed many other examples of how to perform this and tried the code with the same results.

Including the issue/posed here:

https://community.st.com/t5/embedded-software-mcus/when-jumping-to-application-1-or-2-from-custom-bootloader/m-p/170567

I do not have a function:   SYSCFG_MemoryRemapConfig(SYSCFG_MemoryRemap_SRAM); as shown in this example, but I believe it is doing the same things as the HAL function based on reading the reference manual for the STM32F07XX.

[PBaie.1]

I have narrowed down where the issue is located.  We are using a functional safety library.  If I run my bootloader application shifted in flash (no functional safety library) everything works properly. 

However, when I run my actual code I can see that there are a number of functions called prior to my main() where I relocate the vector table.  This was causing the application to crash unless I stepped through most of the process (preventing an interrupt).  

I believe this code is causing the problem:

  #define GotoCompilerStartUp()  { Startup_Copy_Handler(); SystemInit(); __libc_init_array(); main(); }    /* entry to  main() */

The images below show one of the function calls.  STL_StartUp calls HAL_Init as well as 

    SystemCoreClockUpdate(); before my main() is even called.

 

 

I have tried placing my code in the SystemInit() to re-locate the vector table, the issue with this is that the scatter file is read/loaded after this point which clears my vector table once more.

 

 

Any thoughts on how/where to relocate the vector table in this case?

 

 

[PBaie.1]

I was able to get it working.

I had to update my scatter file to make sure the ram location(s) for the vector table was not initialized to 0 when the scatter file values are loaded.

Then I moved code that moves the vector table to RAM into the SystemInit() function so that it was the first thing that happens when transitioning to the application.