• Locked Locked
  • Replies 4 replies
  • Subscribers 119 subscribers
  • Views 6531 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Cortex M3 - how the startup works

Sebastian Gaertner
Note: This was originally posted on 15th May 2009 at http://forums.arm.com

Hi all,

I have some problems understanding the startup procedure of the ARM, here Cortex M3.
Address 0x0000.0000 holds the MSP (main Stack Pointer) and it is the 1st register the Cortex will read after a reset/start.

Address 0x0000.0004 holds the Reset Vector and it will be read after reading the MSP before. Then it jumps to the address that is placed in this register. The rest of the program is then called.

Now the question is: when do I write the values to the both registers at address 0x0 and 0x4?

E.g. if I have my bootcode at address at flash address 0x100 I need to write the value into the register 0x4. But when I power on the device it just will read from 0x4 before I can write to there.
  • Note: This was originally posted on 1st June 2009 at http://forums.arm.com

    with this I get the following error after linking the files:
    Error: L6967E: Entry point (0x00000000) points to a THUMB instruction but is not a valid THUMB code pointer.
    I googled for this problem but could not get a answer that fits.
    Does anybody have an idea why the 0x0 is not a THUMB pointer?


    A pointer to a thumb routine should have bit0 set. However, main (or any other function for that matter) will always be placed at a location which is a multiple of four. So the proper pointer to a thumb main would be (main + 1).
  • Note: This was originally posted on 18th May 2009 at http://forums.arm.com

    Hello,
    yes, right I could remember this now.

    I now used the "exception_table" from the Example3 that comes with the compiler RVDS, located in the exceptions.c file. I chosed also the TWO Region model.
    Please remember that the first 2 entries in this table are:
    (ExecFuncPtr)&Image$$ARM_LIB_STACK$$ZI$$Limit,
    (ExecFuncPtr)&__main, /* Initial PC, set to entry point  */

    And this is the scatter memory layout I chosed:
    ROM_LOAD 0x0000
    {
      ROM_EXEC 0x0000 0x4000
      {
       exceptions.obj (exceptions_area, +FIRST)
       * (InRoot$$Sections)
      }
      RAM 0x10000 0x8000
      {
      * (+RO, +RW, +ZI)
      }
      ARM_LIB_STACK 0x800000 EMPTY 0x10000
      {
      }
    }

    with this I get the following error after linking the files:
    Error: L6967E: Entry point (0x00000000) points to a THUMB instruction but is not a valid THUMB code pointer.


    The .map file show this as a part:

    Memory Map of the image

      Image Entry point : 0x00000000

      Load Region ROM_LOAD (Base: 0x00000000, Size: 0x00007308, Max: 0xffffffff, ABSOLUTE)

    Execution Region ROM_EXEC (Base: 0x00000000, Size: 0x000000f0, Max: 0x00004000, ABSOLUTE)

    Base Addr Size   Type   Attr   Idx E Section Name  Object

    0x00000000   0x00000008   Code   RO    575  * !!!main    __main.o(c_w.b)
    0x00000008   0x00000034   Code   RO    739 !!!scatter    __scatter.o(c_w.b)
    0x0000003c   0x0000001a   Code   RO    741 !!handler_copy   __scatter_copy.o(c_w.b)
    0x00000056   0x00000002   PAD
    0x00000058   0x0000001c   Code   RO    743 !!handler_zi  __scatter_zi.o(c_w.b)
    0x00000074   0x00000030   Data   RO    737 Region$$Table    anon$$obj.o
    0x000000a4   0x0000004c   Data   RW    439 exceptions_area  exceptions.obj


    I googled for this problem but could not get a answer that fits.
    Does anybody have an idea why the 0x0 is not a THUMB pointer?
  • Arm Employee Badge
    Note: This was originally posted on 15th May 2009 at http://forums.arm.com

    The values at these locations are considered non-volatile and should be present before the Cortex-M3 is released from reset. Typically these values will be in the flash/ROM image preloaded onto the device in the same way that your code at 0x100 is.

    hth
    s.

  • The address location 0x4 should be updated while loading the firmware code itself.