cancel
Showing results for 
Search instead for 
Did you mean: 

Interrupts are not triggered during firmware-in-SRAM debugging using ST-Link

Stanley Lin
Associate II
Posted on November 27, 2017 at 11:16

Hi,

I have implemented my application firmware on STM32F746G discovery board and it worked fine while the code was located in embedded flash (just like most examples in cube).

Now I am trying to migrate code to SRAM using ST-Link, to evaluate the execution time between code in flash and RAM.

Current status is that the break points in main() could be reached, but the program was stalled in HAL_Delay() since the interrupt SysTick_Handler() was never triggered. I've spent all day long without finding any useful hint...

My environment is Keil uVision 5, and here is what I did to configure ST-Link debugging in SRAM:

  1. Change memory areas in Target tab

        IROM1: 0x20000000, 0x10000

        IRAM1: 0x20010000, 0x40000
  2. Add a define in C/C++ tab: VECT_TAB_SRAM
  3. Add debug init file (RAM.ini) and uncheck 'Load Application at Startup' in Debug tab

    FUNC void Setup (void) {

      SP = _RDWORD(0x20000000); // Setup Stack Pointer

      PC = _RDWORD(0x20000004); // Setup Program Counter

      XPSR = 0x01000000; // Set Thumb Bit

      _WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register

    }

    LOAD %L INCREMENTAL // Download to RAM

    Setup();

    // g, main

  4. Uncheck 'Update Target before Debugging' in Utilities tab
  5. Press Settings button in Utilities tab, In Flash Download tab

    1. Download function: Do not erase

    2. RAM for Algorithm: 0x20010000, 0x1000

    3. Programming Algorithm: 20000000H - 2000FFFFH

Enclosed is a sample to describe my problem. Note that it's based on cube so it should be placed into the cube directory.

Thanks in advance.

#debug #stm32f7-discovery #st-link
1 ACCEPTED SOLUTION

Accepted Solutions
Stanley Lin
Associate II
Posted on December 29, 2017 at 10:45

I found the root cause from other thread:

https://community.st.com/0D50X00009bMM79SAG

If using CubeMX to generate a new project, there is no problem here.

But if using the project template in STM32F7Cube software, it needs to modify code in system_stm32f7xx.c:

#ifdef VECT_TAB_SRAM

SCB->VTOR = RAMDTCM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

#else

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

#endif

Thanks

Golab.Bogdan

‌'s help!

View solution in original post

2 REPLIES 2
Stanley Lin
Associate II
Posted on December 29, 2017 at 10:45

I found the root cause from other thread:

https://community.st.com/0D50X00009bMM79SAG

If using CubeMX to generate a new project, there is no problem here.

But if using the project template in STM32F7Cube software, it needs to modify code in system_stm32f7xx.c:

#ifdef VECT_TAB_SRAM

SCB->VTOR = RAMDTCM_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal SRAM */

#else

SCB->VTOR = FLASH_BASE | VECT_TAB_OFFSET; /* Vector Table Relocation in Internal FLASH */

#endif

Thanks

Golab.Bogdan

‌'s help!

Posted on December 29, 2017 at 17:30

SCB->VTOR = &__Vectors; // would seem like a more bullet-proof method.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..