...have some of my application code run from RAM?

Comments

5 comments

  • Avatar
    Franco Ricciardi
    I did all this and I find my function correctly transferred to RAM (. fast).
    But the problem is that when I call the function from the main program in C, the jump address is wrong, and jump in flash where find a  "BX  PC" instruction that generates a hard fault.
    Why liker do non allocate the correct address to the calling function ?

    0
    Comment actions Permalink
  • Avatar
    Rod Gilchrist

    Hi Paul,

    I'm trying this out as well and having a very similar issue.

    I try the absolute minimum RAM based function which is 'delay.c' from $(StudioDir)/samples directory of CrossWorks 2.2 on a Mac.

    I snaffle the following code from delay.c into my main.c:

    void delay(volatile unsigned int d) __attribute__((section(".fast")));

    void
    delay(volatile unsigned int d)
    {
    for (;d ;--d);
    }

    And I find that if I comment out the protoytype line with the .fast attribute it works fine and with the prototype line enabled I get a hard fault on a 'bx pc' instruction (Thumb to ARM state change I think) which is in flash and is the second instruction after entry into the delay() function.

    This is on a STM32F103VG target.

    I'm using the default flash_placement.xml.

     

     

    0
    Comment actions Permalink
  • Avatar
    Paul Curtis

    Are you sure you can run from RAM (whever the fast section is placed) on that part?  On some you can't...

    0
    Comment actions Permalink
  • Avatar
    Rod Gilchrist

    Symbol Browser says the .fast segment is at 2000003C-2000005f, so that seems unlikely.

    I actually didn't have the NVIC initialized (i.e. no vector table) when I got the hard fault. When I initialize the NVIC the new behaviour at the same instruction is to branch to 4500e9d2. (The code is 0x4778 (i.e. bx pc) at 0x08001e40 followed by 0x46c0 at location 0x08001e42.)

    The symbol browser doesn't show any segments loaded in that area and none of the registers contained anything like that value before the branch. The debugger halts immediately, as if it only executed one instruction, but no telling really.

    I'm probably smoking something, but some ARM processors have issues with code alignment and switching between ARM and Thumb modes according to section 6.1.1 of this Google hit:

    http://infocenter.arm.com/help/topic/com.arm.doc.uan0002a/UAN002A_1176-pan_use_of_blx.pdf

    Much more likely its something I'm not familiar with in the tools, of course.

     

     

     

    0
    Comment actions Permalink
  • Avatar
    Rod Gilchrist

    And the change in behaviour was me changing the hard fault vector....

    The new address 4500e9d2. is in location 0xC in the new vector table.

    The Rowley start up already sets up the vector table and catches the vector.

    Still a hard fault, then.

    0
    Comment actions Permalink

Please sign in to leave a comment.