[STM32F2xx] Running code from ram.

[root]

Posted on August 02, 2011 at 11:00

Hello,

I'm using tasking which allows easily to tag methods to be copied in ram at startup and then run them from ram.

But I'm wondering at which extend it is a good idea ...

On the one hand, run from ram means zero wait state, so ''performance increase'', but it's not just linear performance increase, it depends on the code itself, and the ART (I'm using an STM32F205) should do a pretty good job at absorbing the 2 wait state of flash.

On the other hand, code and data access would share the same bus, so no parallel read / writes.

Having vector table in ram seems not to be a good option, as the vector fetch happens on another bus while the core stacks the registers, and that's at least 12 clock cycles, so flash wait is not the limiting factor.

I have some small interrupt handlers (like an exti interrupt where I just set an output with reverse polarity) that need low latency (but it seems on this one I'm running a buffered write ''bug'' where the interrupt execute twice - or more - because the interrupt handler ends before the - buffered - bit clear of the interrupt register is done). Would these benefit from being run from RAM?

Regards,

Thomas.

[harry_rostovtsev]

Posted on December 11, 2013 at 00:43

If you have to write to flash, specifically the sector where your image lives, you can only do it while running from RAM.

[chen]

Posted on December 11, 2013 at 16:51

Hi

You are asking a number of questions here. Personally, I would not worry about the speed of execution from Flash or RAM, so long as the execution speed is 'fast enough'. From what you have written - you seem to be concerned about Interrupt Latency. Yes, this is an important issue for a Real Time system. You can calculate the IRQ latency by looking it up in the data sheet. If the best IRQ service time cannot match the required reaction time - back to the drawing board. To achieve best low latency ISR - it is best to hand write the ISR - probably in assembler if you really want speed. You should tell the compiler not to do default ISR compilation (ie not to save all the registers) and do that yourself when you write the ISR. How ? Work out which registers you are going to use and only save those ones. You raised the issue '' it seems on this one I'm running a buffered write ''bug'' where the interrupt execute twice - or more'' I find it unlikely that the IRQs are buffered. IRQs of the same level are pending until they are cleared. If the same IRQ happens again before it has been cleared - nothing happens - they system is not fast enough - go back to the drawing board for a system that can handle the real time requirement! What is more likely happening is that you are getting 'key bounce' which is causing multiple IRQs and each is running correctly as it is suppose to. The problem is the key bounce.

[Tesla DeLorean]

Posted on December 11, 2013 at 17:02

Question from OVER two years ago...

And yes there is a pipeline/write-buffer hazard with clearing interrupts and re-entering, as there is latency in the write to the peripheral, and a reflection in the NVIC state used by the tail-chaining mechanism.