cancel
Showing results for 
Search instead for 
Did you mean: 

Setting VTOR for Application at 0x90000000 on STM32H735

HispaEmo
Associate III

Hi ST Community,

I am working on a bootloader for my STM32H735 board, and I'm encountering issues with setting the Vector Table Offset Register (VTOR) correctly for my application, which is loaded at address 0x90000000. The main problem I'm facing is that the Ethernet interrupt is not firing as expected, which leads me to believe that the VTOR might not be correctly set.

Here's a brief overview of my setup:

  1. Bootloader Configuration:

    My bootloader is running from the internal flash, and it attempts to jump to the application located at 0x90000000.

 

/* Bootloader Code */
#define APPLICATION_ADDRESS 0x90000000

typedef void (*pFunction)(void);
pFunction JumpToApplication;

void Bootloader_JumpToApplication(void)
{
    /* Disable global interrupts */
    __disable_irq();

    /* Disable SysTick interrupt */
    SysTick->CTRL = 0;

    /* Initialize user application's Stack Pointer */
    __set_MSP(*(__IO uint32_t*) APPLICATION_ADDRESS);

    /* Set the Vector Table Offset Register to the application address */
    SCB->VTOR = APPLICATION_ADDRESS;

    /* Get the application's reset handler address and jump to it */
    JumpToApplication = (pFunction) (*(__IO uint32_t*) (APPLICATION_ADDRESS + 4));
    __enable_irq();

    JumpToApplication();

    /* We should never get here as execution is now on user application */
    while(1) { }
}

 

 

2. Main Application Configuration:

In my main application, I also try to set the VTOR to ensure it's correctly pointing to the application's vector table.

 

int main(void)
{
    __disable_irq();
    SCB->VTOR = 0x90000000;
    __DSB();  // Data Synchronization Barrier
    __enable_irq();

    SCB_InvalidateICache();
    SCB_InvalidateDCache();

    MPU_Config();

    SCB_EnableICache();
    SCB_EnableDCache();

    HAL_Init();  

    SystemClock_Config();

    if(Memory_Startup() != MEMORY_OK)
    {
        Error_Handler();
    }

    CPU_CACHE_Disable();

    // Main application logic
    while (1)
    {
    }
}

 

 

3. Linker Script:

My linker script is configured as follows:

 

 

_estack = ORIGIN(RAM_D1) + LENGTH(RAM_D1);    /* end of RAM */
_Min_Heap_Size = 0x1000;      /* required amount of heap  */
_Min_Stack_Size = 0x1000; /* required amount of stack */

MEMORY
{
    ITCMRAM (xrw)    : ORIGIN = 0x00000000,   LENGTH = 64K
    DTCMRAM (xrw)    : ORIGIN = 0x20000000,   LENGTH = 128K
    FLASH    (rx)    : ORIGIN = 0x90000000,   LENGTH = 64M 
    RAM_D1  (xrw)    : ORIGIN = 0x24000000,   LENGTH = 320K
    RAM_D2  (xrw)    : ORIGIN = 0x30000000,   LENGTH = 32K
    RAM_D3  (xrw)    : ORIGIN = 0x38000000,   LENGTH = 16K
    OCTOSPI (xrw)    : ORIGIN = 0x70000000,   LENGTH = 16M
}

SECTIONS
{
    .isr_vector :
    {
        . = ALIGN(4);
        KEEP(*(.isr_vector)) /* Startup code */
        . = ALIGN(4);
    } >FLASH
    /* Other sections follow */
}

 

 



Despite this setup, the Ethernet interrupt never triggers, which leads me to suspect an issue with the VTOR configuration.

I have also tried enabling #define USER_VECT_TAB_ADDRESS in the system_stm32h7xx.c file, but unfortunately, this did not resolve the issue.

Has anyone faced a similar issue or could provide insights on what might be going wrong? Any suggestions or advice on properly setting the VTOR or debugging this issue would be greatly appreciated.

Thank you in advance!

Cheers,
Emo

1 ACCEPTED SOLUTION

Accepted Solutions

Hi ST @STea ,

I wanted to provide an update regarding the issues I was facing with my bootloader for the STM32H735 board, specifically related to setting the Vector Table Offset Register (VTOR) for my application loaded at address 0x90000000.

After thorough investigation and debugging, I found that the bootloader implementation was entirely correct. The root cause of the problem was related to the configuration of the Memory Protection Unit (MPU) and the cache in my main application.

Once I correctly configured the MPU and the cache settings in my application, the jump to the application executed without any issues. This adjustment resolved the problem, and the Ethernet interrupt started firing as expected.

Thank you to everyone who provided insights and suggestions.

Best regards,

View solution in original post

4 REPLIES 4
STea
ST Employee

Hello @HispaEmo ,

The external memory application is based on a specific boot schema, which is different from the standard one and
which supports a smooth transition from the on-chip application to the off-chip application.
There are two updates that must be done by the user as the location of the application has changed:
• Ensure the usage of the required linker file with memory mapping that corresponds to the selected boot
option.
• Update the settings of VTOR to use the right address. 
for more details on this see section 5.2 Load and debug of this Application Note.

In fact, the user application must be stored into the SPI-NOR Flash memory at the address 0x90000000. It has to
be done using the STM32CubeProgrammer. The output of the application must be in binary format in order
to be able to specify a different load address which is the SPI-Flash address.
you can refer to the examples in  STM32Cube_FW_H7_V1.11.0\Projects\STM32H735G-DK\Applications\ExtMem_CodeExecution found in the CubeH7Firmware and Github .

Regards

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
STea
ST Employee

Hello @HispaEmo ,

any update on this topic?

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hi ST @STea ,

I wanted to provide an update regarding the issues I was facing with my bootloader for the STM32H735 board, specifically related to setting the Vector Table Offset Register (VTOR) for my application loaded at address 0x90000000.

After thorough investigation and debugging, I found that the bootloader implementation was entirely correct. The root cause of the problem was related to the configuration of the Memory Protection Unit (MPU) and the cache in my main application.

Once I correctly configured the MPU and the cache settings in my application, the jump to the application executed without any issues. This adjustment resolved the problem, and the Ethernet interrupt started firing as expected.

Thank you to everyone who provided insights and suggestions.

Best regards,

Hello @HispaEmo ,

glad to hear it's working, good luck.

 

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.