Running code from RAM

[slal]

Posted on September 16, 2013 at 22:20

Hi all!

I am wondering if anyone has tried jumping from flash code to an entire project in internal SRAM without resetting (so no memory remap / boot0/boot1 config is required). I am working on the STM32F417, and have managed to jump from flash code to the main( ) function of the SRAM project. The main code works fine, however no interrupts are being generated.Here are my observations:- vector table is in place (address 0 of SRAM) and points to correct locations in SRAM for where the individual IRQ_Handlers are placed (which I confirm with the .map file from the linker).- the interrupt bit is being set properly.- the NVIC active bit is also being set for the interrupt, e.g. TIM3 interrupt, however the code never enters TIM3_IRQHandler( ).Has anyone had experience with such a situation? With an older ARM7 core, it was easier to set the boot mode to ''from internal SRAM'' and simply reset the core. However, I don't seem to have the same facility in this case (unless I physically set the boot0/boot1 pins high in hardware). #code-in-ram #memory-remap

[Tesla DeLorean]

Posted on September 18, 2013 at 22:45

Depends on how symbiotic the two pieces of code are. If the two are free standing, then yes you'd want to jump to the Reset_Handler code, which in turn calls SystemInit(),  the C runtime startup code, and then main(). In the case of Keil the SP is set elsewhere. On the other hand if the code is something which is self contained, it can be copied to RAM, and executed via it's entry point. If you circumvent required startup code/requirements you'll clearly have a bad day.

[damh]

Posted on September 19, 2013 at 11:10

A hint (probably not your solution):

Some STM32F... have a problem with hardware breakpoints in RAM. We have to use software breakpoints (like asm(''bkpt ...'')) in our devices, if we are using RAM-Code. A second hint/question: Did you use an ISB-operation after writing to SCB->VTOR? A third hint: I read you use SCB->VTOR = 0x20000000. If you use a diffent address, keep in mind, that the ARM-Cortex M3 has a clipping/cropping/cutting feature for the vector table, so only the top x vectors are used!

[slal]

Posted on September 20, 2013 at 14:29

I received an example from an ST FAE however it only shows a flash application that right away jumps to RAM application. That seems to work ok with interrupts etc in RAM, however the flash application does not initialise any peripherals or interrupts of its own, so I can't really compare that to my scenario.

I wonder if I'm not allocating things properly in the RAM project - I've not really separated ROM address from RAM address in it, both ranges are set from 0x20000000 to 0x2001FF7F.

[Tesla DeLorean]

Posted on September 20, 2013 at 16:14

Well you definately need to floor-plan how the RAM is being used so you don't step on yourself.

Reseting and transiting to RAM code is a common way to enter that code in near reset conditions. You want to keep the peripherals/clocks in a functional state, and you'll have to manage the hand-off of peripherals and resources.

https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Help%20with%20application%20jump%20to%20system%20memory%20boot&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD0...

[slal]

Posted on October 08, 2013 at 16:37

Thanks for the insight Clive1. I didn't manage to debug the problem when running with the RTOS, however as a work-around I just use a rather convoluted function in RAM to act as the secondary application for now. All this information was nevertheless helpful for future projects.