Vector table relocation works only in debug mode

Posted on February 18, 2018 at 19:23

Hi,

I'm facing a problem with relocation of the vector table to the internal SRAM. I work with the STM32F030CCT6 (using the Ac6 System Workbench and CubeMX, with the HAL libraries 1.9.0) and I want to design a simple bootloader.

This is a part of my linker script:

/* Specify the memory areas */

MEMORY

{

RAM (xrw)      : ORIGIN = 0x200000C0, LENGTH = 32K-0xC0

VTRAM (xrw)    : ORIGIN = 0x20000000, LENGTH = 0xC0

FLASH (rx)     : ORIGIN = 0x08000800, LENGTH = 256K-0x800

}

....RAMVectorTable(NOLOAD): {*(.RAMVectorTable)} >VTRAM

This is a vector table relocation in the main() of the bootloader:

__IO uint32_t VectorTable[48] __attribute__((section('.RAMVectorTable')));

/* USER CODE END 0 */

/**

  * @brief  The application entry point.

  *

  * @retval None

  */

int main(void)

{

  /* USER CODE BEGIN 1 */

  uint32_t i = 0;

  for(i = 0; i < 48; i++)

    VectorTable[i] = *(__IO uint32_t*)((uint32_t)0x08000800 + (i<<2));

  /* Enable the SYSCFG peripheral clock*/

  __HAL_RCC_SYSCFG_CLK_ENABLE();

  /* Remap SRAM at 0x00000000 */

  __HAL_SYSCFG_REMAPMEMORY_SRAM();

...

Later on I send some test messages over the UART interface. I do not know why, but the above code works perfectly in the debug mode - I just need to run 'debug' and then 'resume' the program execution (with or without breakpoints later, does not matter).

Nevertheless, if I program the target (right click on the project -> 'Target' -> 'Program chip...', or just power-reset what I uploaded during the debug session), there is no response from the board. I am pretty sure that finally there is the same program on flash since I use the same .elf file both for the debugging session and regular programming... However, I've checked that if I do not relocate the vector table and I program the flash from the beginning (flash starts at 0x08000000), everything works just fine.

Just to clarify - I want to program the bootloader with some offset (0x0800) in memory because I need some space for the bootloader sensitive data (bootheader).

BR,

Marek