• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 1858 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RE: SYSRSTIV reset value for msp430

Bhushan Patil10
Prodigy 160 points
Other Parts Discussed in Thread: MSP430F5419A

Hi Katie,

I have come across same issue.

I am using MSP430F5419A with IAR5.51 IDE.

               ****************************************

               *                                      *

               *            RUNTIME MODEL             *

               *                                      *

               ****************************************

 __SystemLibrary = CLib

 __core          = 430X

 __data_model    = large

 __double_size   = 32

 __pic           = no

 __reg_r4        = regvar

 __reg_r5        = free

 __rt_version    = 3

Basically I have divided the whole memory map in 2 banks(36K each).

Bank1 : 0x5C00 - 0xEC00

Bank2 : 0x10000 - 0x19000.

An aaplication code places in bank 1 works fine.

But when the same code is placed at bank2, at some function calls PUC occurs.

Checked the SYSRSTIV it shows a value 0x001E.

What must be the issue? As the same code works fine below 64K.

Thanks

Bhushan P

  • 0
    Guru 227245 points
    0x001e means the processor was trying to fetch an insctuciton from peripheral/conficuration area.
    Most likely, the program counter somehow reached 0x0000 (or alike).
    To run code above 0x10000, you need to run it in large code model (well, that should be the default anyway).
    The apllies to all code. Including assembly or library code that is linked-in. The code needs to use CALLA to call functions, and RETA to return from a function. (for ISR calls, the upper 4 bit of the return address are always saved together with the status register and always restored by RETI)
    If code is called by CALLA but contains only a RET, it will ignore the upper bits of the stored return address and return to an address in the lower 64k (also leaving two bytes on the stack).
    Also, ISRs need to be in the lower 64k memory, as the itnerrupt vectors are only 16 bit wide. An ISR may then jump to code in the upper memory, but it MUST begin below 0x0FF80.
  • 0
    TI__Guru* 79161 points
    Hi Bhushan,

    Are you forcing ALL of your code into Bank2? This can't be done because the interrupt vector table entries are only 16-bit, so they cannot point to a 20-bit address. That means that any ISRs must go in lower memory, and also that the entry point for your code pointed to by the reset vector must also be in lower memory. The default linker files usually handle this by having a section for ISRs that is specifically placed in lower memory by default, and doing something similar with the functions for the c initialization that contains your entry point cint00.

    I'm not sure about everything you've changed in your project to see how you are placing code in memory, but this is most likely related to your problem, and you'll have to revert some changes or make other changes to your linker file/code placement.

    What is the purpose of putting your code exclusively in the upper flash? Are you trying to have some sort of bootloader with dual-image support? If you want to do something like this, you will probably need to implement some sort of proxy interrupt vector table to redirect your interrupts into your ISRs in the upper memory - the app note on MSPBoot www.ti.com/.../slaa600 has some information and code that shows how to do vector redirection, albeit for code in lower memory only. You'd have to make some modifications, but there are other threads that address some of this: e2e.ti.com/.../1402558
    e2e.ti.com/.../1559629
    e2e.ti.com/.../1546624

    Regards,
    Katie
  • 0 in reply to Jens-Michael Gross
    Prodigy 160 points
    Hi Jens-Michael,

    I have a boot code which is stored at address 0xFC00 - 0xF7FF.
    Boot code uses actual INTVEC table from 0xFF80 - 0xFFFF.

    Where as application code stored either in bank 1 or bank2, uses RAM vector table.

    As the application code is above 0x10000, I have created INTVEC_RAM of 4 byte each(This is the change what I did from code below 64K).

    But still I get the same issue of 0x1E.

    As you have mentioned I cross verified the lst file. List file shows CALLA and RETA. Hence generated code is proper for MSP430X.

    One more doubt, how do I find the exact instruction creates System Reset.

    Thanks
    Bhushan
  • 0 in reply to Katie Pier
    Prodigy 160 points
    Hi Katie,

    You got me right.

    I want to have dual images at bank 1 and bank 2.

    And for the same I have used RAM intevec table(SYSCTL.SYSRIVECT = 1).

    This works fine if the code is below 64K because proxy INTVEC table is of 2 byte length and can access the ISR correctly.

    But same creates issue. So I have created an INTVEC table with 4byte length each. But this doesnot help me solve the issue.

    I have stored my INTVEC table at,
    INTVEC 0001000C - 00010103 F8 rel 1

    I guess whenever interrupt happens PC fetches ISR address from RAM, but accesses only 16-bit. So instead of 0x1000C it access 0x000C whihc peripheral area. This is just a guess about the execution.

    How to confirm when interrupt happens which ISR address is picked?
    So that my understanding about above behaviour is correct.

    Regards,
    Bhushan
  • 0 in reply to Bhushan Patil10
    Guru 58965 points

    Bhushan Patil10 said:
    I guess whenever interrupt happens PC fetches ISR address from RAM, but accesses only 16-bit. So instead of 0x1000C it access 0x000C whihc peripheral area. This is just a guess about the execution.

    That is correct.

    You could use 16-bit INTVEC (either in Flash or in SRAM) to point to a "BRA" instruction (with 20-bit destination) stored in the lower 64K (either in Flash or in SRAM).

  • 0 in reply to Bhushan Patil10
    Prodigy 160 points
    Hi Katie,

    A basic question is it possible to define 4-byte interrupt vector table in RAM in MSP430.

    Is there any architecture limitation?

    Thanks
    Bhushan
  • 0 in reply to old_cow_yellow
    Prodigy 160 points

    Hello,

    A basic question is it possible to define 4-byte interrupt vector table in RAM in MSP430.

    Is there any architecture limitation?

    I have defined something like this for 2 byte interrupt vector table,

    #define iv0helper( func )

    #define iv1helper( func )

    ....

    #define iv61helper( func )

    #define iv62helper( func )

           ORG     0

    #define iv0helper( func )       DC16    (func)

           ORG     2

    #define iv1helper( func )       DC16    (func)

    So, when I change the same to 4 byte like,

    #define iv0helper( func )

    #define iv1helper( func )

    ....

    #define iv61helper( func )

    #define iv62helper( func )

           ORG     0

    #define iv0helper( func )       DC32    (func)

           ORG     4

    #define iv1helper( func )       DC32    (func)

    and so on....

    MSP430 still gives me SYS reset(0x001E).

    Thanks

    Bhushan

  • 0 in reply to Bhushan Patil10
    Guru 318700 points
    is it possible to define 4-byte interrupt vector table

    No. As you were already told, interrupt vectors always have 16 bits. So you have to put the interrupt handler into lower memory (even if it's just a 20-bit jump elsewhere).

**Attention** This is a public forum