cancel
Showing results for 
Search instead for 
Did you mean: 

stm32f3 moving ISR vector

dooz
Associate II
Posted on September 03, 2015 at 14:57

I'm using flash memory in my project so in order the interrupts to work properly I have to move the ISR vector to SRAM or else the flash will stall the interrupts during its work.

My working environment is CubeMX and System Workbench for stm32. 

The question is: how to do this?

After I have generated my project configuration I found a file system_stm32f3xx.c.

In this file there are lines:

/*!< Uncomment the following line if you need to relocate your vector Table in

     Internal SRAM. */

/* #define VECT_TAB_SRAM */

#define VECT_TAB_OFFSET  0x0 /*!< Vector Table base offset field.

                                  This value must be a multiple of 0x200. */

/**

.

.

.

.

#ifdef VECT_TAB_SRAM

  SCB->VTOR = SRAM_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

}

So I just have to uncomment this line and I will get what I want?

Second question is about using extern ''C'' phrase.

I did it on my timer interrupt definition lets say it looked like that:

extern ''C'' void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)

{

   if (htim->Instance==TIM3)

      {

      licznik=licznik+1;

      }

}

but the compiler says it's a syntax error. Am I using it in a wrong way or maybe I need a library to use this phrase.

Last question is about moving my code do SRAM. I browsed through a few topics, tried looking into manual but still don't know how to do it. Can anyone advise me in this matter?

Regards

10 REPLIES 10
Posted on September 04, 2015 at 04:52

I wrote a response to this this morning, but the browser ate it...

The 'extern ''C''' stuff is only required if you're using a C++ compiler, or a .cpp file, where the name would otherwise get mangled.

Changing the SCB->VTOR tells the CPU where to look for the vector table, it doesn't alter the behaviour of the linker in terms of code placement. I don't think the define does a memcpy() of the vector table into RAM either, not alter the RAM region in the linker to carve out space for the vector table.

There are usually pragmas and directives for getting function into RAM, and this will cause the runtime/startup code to copy them there.

And alternative is to build a RAM based image, and then have a smaller loader function in FLASH, that basically memcpy()'s the entire thing into RAM and jumps to it.

Most of these things require a good grasp of the micro-controller (how it behaves and executes code), and the tools (compiler, linker, loader type stuff)

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dooz
Associate II
Posted on September 04, 2015 at 11:00

I tried 5 times to replay but everytime an error occured -_-

Too bad for me, I thought this operation is much easier for example like described in here:

[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/vector%20table%20location&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B&currentviews=1892]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fvector%20table%20location&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=1892

Either way I have to make this work so please give me some links or describe how can I go through this process.

Posted on September 04, 2015 at 22:33

Ask yourself if your entire app+data can fit in the available RAM. If it can you could set up the linker script to build it there, and the SystemInit() code to select a RAM basis for the vector table. You'll then want to package this application with a small ROM loader to copy it into RAM and jump to it when the system starts.

The problem with 'moving the ISR vector' to RAM, is that everything it calls needs to be in RAM also, otherwise the first thing to touch FLASH will cause it to stall when thearray has an erase/write operation pending against it.

If you just want to move the vector table, carve out an area at the base of RAM (linker script description of regions and sections), and memcpy() a version of it there in SystemInit(), before you point SCB->VTOR at the new RAM based table.

I'm not using Cube or System Workspace, you'll have to own those choices, but I can't see much detail in the code snippet provided here to convince me that there's code you redacted that actually does any copying of the vector table. I'm going to assume the define relates to code built to be downloaded/debugged in RAM.

Building a complete worked example would take a couple of hours.

Review how the linker scripts allows you to control placement of functions or objects. Review how the compiler provides directives or pragmas to direct variables/functions into specific sections.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dooz
Associate II
Posted on September 07, 2015 at 08:40

Thanks for the answer, I'll take a deeper look at all these operations you described above.

I think I'll be able to copy the entire code into RAM.

Regards

dooz
Associate II
Posted on September 08, 2015 at 10:37

Clive, can you please look at this topic and tell me if the ld file is going to work?

http://forum.chibios.org/phpbb/viewtopic.php?f=16&t=2750&p=22150#p22150

dooz
Associate II
Posted on September 08, 2015 at 13:02

I've found something really useful :)  There is an application note that somehow describes how to move code to RAM or make an interrupt from RAM memory. It's here:

http://www.st.com/web/en/resource/technical/document/application_note/DM00083249.pdf

but I'm still looking for some data about copying the entire ISR vector.

Posted on September 09, 2015 at 04:31

Like I said ''Building a complete worked example would take a couple of hours'', and I have my own projects to work on, you're going to have to invest your time in understanding the micro-processor and the tools.

Assuming the vector table is 0x188 bytes in length.

memcpy(0x10000000,0x08000000,0x188); // Move Vector Table from FLASH to CCMRAM

SCB->VTOR = 0x10000000; // Point at CCMRAM copy

Make sure the linker script shrinks the CCMRAM from

CCM (xrw) : ORIGIN = 0x10000000, LENGTH = 0x1000

to

CCM (xrw) : ORIGIN = 0x10000188, LENGTH = 0x0E78

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
dooz
Associate II
Posted on September 09, 2015 at 13:21

About this memcpy function. Did you check how it works or just wrote in the post how it should approximetly looks like?

I'm asking because in my code the compiler is shouting.

Posted on September 09, 2015 at 17:28

I wrote it free-hand, to infer the functionality required to copy the table some place else. If the compiler complains about the things not being address pointers, presumably casting them as (void *) would make it happy.

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