• State TI Thinks Resolved
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 6187 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

MSP430FR5994: Linking_error

rachit choudhary
Prodigy 70 points
Part Number: MSP430FR5994

Hi 

I am getting this error while i am using it in debugger mode.

  • 0
    TI__Guru 68116 points
    Hi rachit,

    Thanks for posting. In order to best help you, can you please help provide some of the following information:
    1. Can you please let us know what version of IAR you are using, so that we can try to reproduce the issue?
    2. Do you see this issue with any code project for MSP430FR5994 that you try to load, or only with this particular one?
    2a. If it's only happening with this code, can you please give us more information about the project? It looks like you may be porting MSPBoot? Are you aware of MSP430FRBoot for FRAM devices, including an FR5994 example? Are there any pre-built libraries that you are including?

    It looks like it is having an error about LEA_SC and LEASC in register/bit definitions. The name of the module was changed in header/linker files before device release from being called LEA_SC to being called just LEA - so it could be a versioning issue here. The information you provide will hopefully allow us to reproduce and find where the reference to LEA_SC is still existing in your case.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 70 points
    1. IAR version is 6.50.1
    2. Only with this code i was this.
    2a. Yes I am porting MSPBoot from 5969 to 5994, i will the fr5994 changes.

    I will look this LEA_SC and LEASC in register, will notify you if got any response.


    Regards
    Rachit
  • 0 in reply to rachit choudhary
    TI__Guru 68116 points
    Hi rachit,

    You may want to try updating to the latest IAR version to see if that resolves the issue. That should have the latest header file and linker file versions.

    Regards,
    Katie
  • 0 in reply to Katie Pier
    TI__Guru 68116 points
    Hi rachit,

    Were you able to resolve your issue? Is there anything else we can do to help?

    Regards,
    Katie
  • 0 in reply to Katie Pier
    Prodigy 70 points

    Hi Katie,

    As of now, i am able to compile the code.Still unable to use the interrupts from the application code.

    Facing the issues when using the _App_Proxy_Vector_Start and Vector table.

    Want to know about the diag_suppress=Pe767, how this is calculated

    #pragma diag_suppress=Pe767
    *((uint16_t *)(_App_Proxy_Vector_Start + RTC_VECTOR - 59)) = (uint16_t)RTC_C_ISR;            // here 59 stands for ?

    *((uint16_t *)(_App_Proxy_Vector_Start + PORT4_VECTOR - 59)) = (uint16_t)Port_4;

    In TI_MSPBoot_VecRed_FR5969 .. file BRA instruction (0x4030) followed by the address of each

    vector routine. It will change for the 5994 or not, how this BRA instruction followed.

    0x4030, (uint16_t)&_App_Reset_Vector[0], // APP_PROXY_VECTOR(0) // FFCC = AES256
    0x4030, (uint16_t)&_App_Reset_Vector[0], // APP_PROXY_VECTOR(1) // FFCE = RTC

    Thanks 

    Rachit 

  • 0 in reply to rachit choudhary
    TI__Genius 15370 points

    Hi Rachit,

    It looks like you're trying to port MSPBoot to an MSP430FR5994. Is that correct?

    MSPBoot was created mainly for flash devices and handles interrupts in a much different, more complex way due to flash segmentation. This involves the use of a proxy vector table like what you've described above. I would not recommend this as a starting place for you project. Even if you've already started developing your code this way, i encourage you to start with MSP430FRBoot instead.

    MSP430FRBoot was made for FRAM devices including the MSP430FR5994 and does not require a proxy vector table for interrupts. This means there is no vector redirection and interrupt handling is almost the same as in a typical application. Using this as a starting place will solve the issues you're currently seeing with interrupts.

    Here is a link to the MSP430FRBoot Application Report and code (Including MSP430FR5994): MSP430FRBoot 1_00_00_00

    Best regards, 
    Caleb Overbay

  • 0 in reply to rachit choudhary
    TI__Genius 15370 points
    Hi Rachit,

    Do you still need help with this issue? If you were able to resolve it, could you update the post with what you did to fix your issue?

    Best regards,
    Caleb Overbay
  • 0 in reply to Caleb Overbay
    Prodigy 70 points

    Hi Caleb,

    While coding the bootloader:
    Any interrupts used by the bootloader are marked 'RESERVED' in TI_MSPBoot_VecRed_FR5969.c/5994.c
    In the bootloader's main.c, between the diag_suppress=Pe767, enter the functions necessary for bootloader interrupt functionality using the appropriate offset defines.
    During compile of bootloader:
    The memory protected vector table (ending at 0xFFFE) is filled with the addresses of the proxy vector table entries (which will eventually live in the main app)
    When the bootloader runs:
    At start, it will copy the appropriate interrupts into the memory protected vector table BEFORE turning memory protection on, these will remain for the duration of run time
    The glue:
    The location of the proxy vector table location is defined in the linker file for BOTH the bootloader and main app, and must be the same in order for both binaries to interoperate. (In general the upper portion of either linker file (.xcl) should look complimentary, and a change in one should merit an evaluation of whether or not it affects the other)
    While coding the main app:
    Any interrupts used by the bootloader will NOT be available to the main app (ref. TI_MSPBoot_VecRed_FR5969.c/5994.c)
    At the start of the application main function, between the diag_suppress=Pe767, enter the functions necessary for interrupt functionality using the appropriate offset defines.
    During app compile:
    The proxy vector table will be taken from TI_MSPBoot_VecRed_FR5969.c/5994.c and written into the application memory space.
    When the main app runs:
    As coded, it will copy the appropriate interrupt addresses into the proxy table, which basically 'registers' the forwarding of the hardware interrupt to the desired app isr function that exists in your source code/modules.
    When a hardware interrupt occurs:
    The mcu will branch to the corresponding address in the proxy table, unless the vector is reserved by the bootloader, in which case the bootloader isr is called directly.
    If an isr function has been 'registered' by the application for the corresponding entry then it will be executed, otherwise the default proxy entry will be called, which is the reset vector of the application.
    Thanks & Regards
    Rachit Choudhary

  • 0 in reply to rachit choudhary
    TI__Genius 15370 points
    Hi Rachit,

    It looks like you didn't start with MSP430FRBoot and instead ported MSPBoot to the MSP430FR5994. This must have taken a lot of time and effort! Much of what you've described above is unnecessary with FRBoot and it looks like there has been some added complexity to your solution. Is there a reason you decided not to base your code on MSP430FRBoot?

    If you're still having issues, I urge you to look into MSP430FRBoot.

    Best regards,
    Caleb Overbay
  • 0 in reply to Caleb Overbay
    Prodigy 70 points

    Hi Caleb,

    I was having dependency of previous code,In previous code they have defined variables (macros) with different names and parameters and they were using the Boot_vector_table. 

    I have to use them,because they have dependency in complete code, that's  why i have used this code only.

    Even i have tried with your solution also, by calling  one ISR from the boot_vector_table. it works fine.

    Thanks & Regards

    Rachit Choudhary

**Attention** This is a public forum