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 16, 2013 at 22:27

You don't need to remap RAM to zero, you can compile your code to reside at 0x20000000, and have it set the vector table (SCB->VTOR) to that address. VTOR can be any 512-byte boundary address.

On ARM 7 and 9 parts you had to remap at zero because you COULDN'T change the addresses the processor vectored through. This is not the case for Cortex-M3/M4 parts. On a Cortex-M0 (STM32F0) part, you also can't change the vector table, and the trick there is to either map FLASH at zero, or copy a small vector table into RAM, and then map RAM at zero.

[slal]

Posted on September 16, 2013 at 22:58

Thanks for replying Clive1.

Infact, the first thing I do in the main( ) of the RAM project once it loads is to set the VTOR. I call the STM library function as follows:NVIC_SetVectorTable( NVIC_VectTab_RAM, 0 );This should map all vectors properly, and it does. I check register values and they are appropriate. I see that the location where the linker places my IRQHandler( ) is also correctly listed in the vector table which is now at base address of RAM (0x20000000).

[Tesla DeLorean]

Posted on September 16, 2013 at 23:16

How are you debugging your IRQHandler issue?

Can you toggle a GPIO, or breakpoint it?

[slal]

Posted on September 16, 2013 at 23:43

Yes, I am toggling an output pin (driving an LED). I even thought that maybe the flash IRQHandler is still being called, but that's not the case either.

[slal]

Posted on September 16, 2013 at 23:45

And when I load the RAM application independently into RAM I can debug it and it all runs correctly. It's just when I jump from the flash application that the ISRs don't run.

[Tesla DeLorean]

Posted on September 17, 2013 at 00:53

Something else going on here, try to create a very simple test example.

How are you partitioning RAM between the app, statics, heap, and stack?What board are you using, what pins for USART, LED, etc?

[slal]

Posted on September 17, 2013 at 14:48

I simplified my code to just have a timer (TIM3) and three USARTs (USART1/3/6) and then copy to RAM and jump to the RAM application, which has the same timer along with USART3 being initialised again. Nothing changed - the timer interrupt is being set, but it's not going anywhere.

I am using IAR's toolchain, and I've set the ROM and RAM areas in the linker file to SRAM base address. Also, I've limited the end of ROM/RAM to 0x2001FF7F, so that I can reserve 0x80 bytes for some shared variables between the two projects. There is zero heap size, and the stack is being placed at a much higher location in SRAM so I don't think it is being corrupted.I'm using a custom-designed board with the STM32F417IG. I've already had some trouble with the I2C2 peripheral, which turned out to be listed in the errata too. The pins I'm using for USART1 are PA9/10, for USART3 are PC10/11, and for USART6 are PG9/14.I must also mention that I'm using an RTOS, which I do disable before jumping to the RAM application. Thanks for your input!

[Tesla DeLorean]

Posted on September 18, 2013 at 04:39 The original post was too long to process during our migration. Please click on the provided URL to read the original post. https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I6cz&d=%2Fa%2F0X0000000bs2%2FcyTx1qLN7JQ.Nl519R3_7Rje5BMKLzV8cUjO8L39Sdg&asPdf=false

[chen]

Posted on September 18, 2013 at 17:35

Hi

The problem is that you do not just 'jump to main' in the ram application. Both the Program counter AND the Stack Pointer need to be changed. This is done at boot up by the first 2 entries in the vector table. Entry 0 is the stack pointer address Entry 1 is the Program counter address I was trying to do a similar thing, I wanted to have a Bootloader program and an application program, both in Flash. For the bootloader to start the application, the bootloader has to effective load both the stack pointer and program counter. I searched for example bootloader code to do this and got my answer.