Interrupts are not triggered during firmware-in-SRAM debugging using ST-Link
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-11-27 2:16 AM
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:
- Change memory areas in Target tab IROM1: 0x20000000, 0x10000 IRAM1: 0x20010000, 0x40000
- Add a define in C/C++ tab: VECT_TAB_SRAM
- 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
- Uncheck 'Update Target before Debugging' in Utilities tab
- Press Settings button in Utilities tab, In Flash Download tab1. Download function: Do not erase2. RAM for Algorithm: 0x20010000, 0x10003. 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-linkSolved! Go to Solution.
- Labels:
-
DEBUG
-
ST-Link
-
STM32F7 Series
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-12-29 1:45 AM
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 */ #endifThanks
Golab.Bogdan
‌'s help!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-12-29 1:45 AM
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 */ #endifThanks
Golab.Bogdan
‌'s help!- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2017-12-29 9:30 AM
SCB->VTOR = &__Vectors; // would seem like a more bullet-proof method.
Up vote any posts that you find helpful, it shows what's working..
