• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 78 subscribers
  • Views 826 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.

CCS/MSP430FR5994: MSP430FR5994 Memory Allocation

MICHAEL MACLEAN
Intellectual 575 points
Part Number: MSP430FR5994

Tool/software: Code Composer Studio

Hi folks,

Is it possible to specify a fram section, then somehow ensure either a file or function can be placed in this section?

I can use pragma location for setting an explicit address per variable or function, but I don’t want to manage this, I just want to have certain code placed in a certain section. E.g. “.text2” or something, and then place my serial command processor code goes there.

  • Critical code, (isr and non isr) - Would like to place in the lower 64k to try and ensure 16bit shorter instructions (fast as poss)
  • Non-critical code and constants – Would like to place from 64k onwards
  • Storage area for data – must be as large as possible, min 160kB, but doesn’t need to be fast

 

This led me to a memory plan on the MSP430FR5994 of:

Bottom 48kB (up to isr vectors) for the main code / isr()s, 48k from after isr vectors (0x10000 onwards) for constants and other data storage, remaining 160kB for the main data store.

I was hoping the main code would comfortably fit in 48k but the bloat from debug printing and some libraries take it above 48k. I have debug / test code for printing results etc, this is the biggest size (lots of strings) but the least important.

Ive already made some mods to the linker file, but im finding this harder than perhaps it should be, and I cant find decent documentation on the linker file. Any help on setting it up to for the above scheme, (or any reasons itf it’s a bad idea) would be a great help.

 

thanks,

michael.

  • 0
    TI__Mastermind 38410 points

    Hi, 

    Yes, you can. Please refer to the compiler user guide.5736.MSP430 Optimizing C Compiler User Guide.pdf

    In section 5.12.6 and section 5.12.7, you can find the answer.

    Eason

  • 0 in reply to Eason Zhou
    Intellectual 575 points

    Hi Eason, 

    thanks i had missed that in the compiler guide.  seems to have done the job. 

    regards, 

    michael. 

  • 0 in reply to MICHAEL MACLEAN
    Intellectual 575 points

    Hi again, 

    I've started to have problems with this.  My program hangs as soon as it gets to the first line in the relocated function. 

    The relocation is to address 0x10400.

    if i comment out the CODE_SECTION pragma the code works fine (the function is place in the lower 64kB).  

    i noticed that when running in debug, it stops at the first line as well. When i step through (assembly):

    on the broken version, it takes two steps to complete one instruction, and noticed the Program Counter increments by 2 then 4.  (e.g. i click the green arrow twice before it goes to the next line.  first time PC -> 0x10402, second PC -> 0x10406)

    on the working version:  it takes a single step to complete (as expected), and the program counter increments by 6  (PC -> 0x10406) . BICX.B 3 word instruction shown below, so also expected

  • 0 in reply to MICHAEL MACLEAN
    TI__Mastermind 38410 points
    Hi,
    1. My program hangs as soon as it gets to the first line in the relocated function.
    What do you mean? The PC doesn't block on 0x10400, and run to 0x10406.
    2. Can you compare the asm code between using relocated function and not using it?
    Eason
  • 0 in reply to Eason Zhou
    Intellectual 575 points
    Hi
    1. its stays at 0x10400 when i hit 'run'. The debugger still thinks its running, but when i hit pause, its still at 0x10400. BUT, when i step through the code, its does actually run to 0x10406 (i have to step twice, PC goes to 0x10402 then 0x10406).

    2. the asm code is identical, it just appears in a different location. it looks exactly the same as the snaphot above, but starts somewhere around 0x6000. (not at my desk at the moment so cant check exactly where).

    cheers,
    michael.
  • 0 in reply to MICHAEL MACLEAN
    TI__Mastermind 38410 points

    Hi,
    So you mean if you use debug in C code it stops at 0x10400. If you debug in asm code, it run normally?
    1. If so I advice you to let the MCU run at free mode and use a LED as a test signal to see if it is really stopped there.
    2. Another possible, the code just jump to 0x10400 after finishing the init function, as a result your code generate a loop.
    Please check it.
    Eason

  • 0 in reply to Eason Zhou
    Intellectual 575 points

    Eason Zhou said:

    Hi,
    So you mean if you use debug in C code it stops at 0x10400. If you debug in asm code, it run normally?
    1. If so I advice you to let the MCU run at free mode and use a LED as a test signal to see if it is really stopped there.
    2. Another possible, the code just jump to 0x10400 after finishing the init function, as a result your code generate a loop.
    Please check it.
    Eason

    No, i don't mean that. the code has really stopped there, firstly i checked with a test signal as you mentioned in pt 1. i then ran debug and get the results as i posted above (C or asm, the same thing happens). 

    2. im not sure i follow.  do you mean at the end of hal_board_init function?  i dont think so because if i set a breakpoint half way down this function it never gets there.

    thanks,

    michael.

  • 0 in reply to MICHAEL MACLEAN
    TI__Mastermind 38410 points

    Hi,

    1. Can you try to run to wrong code without debug, just in free run mode?

    2. I can't understand this description clearly, what do you mean? it seems that the program all run to 0x10406, and not stop at 0x10400.

    on the broken version, it takes two steps to complete one instruction, and noticed the Program Counter increments by 2 then 4.  (e.g. i click the green arrow twice before it goes to the next line.  first time PC -> 0x10402, second PC -> 0x10406)

    on the working version:  it takes a single step to complete (as expected), and the program counter increments by 6  (PC -> 0x10406) . BICX.B 3 word instruction shown below, so also expected

    Eason

  • 0 in reply to Eason Zhou
    Intellectual 575 points

    sorry maybe i wasn't clear.  the msp hangs (non responsive) when running normally, WITHOUT the debugger. 

    i then tried debugging to find the problem. the program stops at 0x10400 which is the first line of the relocated function.

    Anyway I've discovered the problem, i forgot to update the MPU to allow this segment to execute code. previously 0x10000 and above were setup for data, and the MPU configured this segment to 'RW' but after deciding to move some code here, i forgot to change the settings to 'RX'.  have updated and it runs fine now.

    Regards,

    Michael.

**Attention** This is a public forum