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: Use 8 kByte RAM

Part Number: MSP430FR5994

Hello,
my software needs more than 4 Kbytes of RAM. LEA is not required. I would like to use the RAM of the LEA through the programme. Unfortunately, inexplicable changes of the content happen in this RAM area. I found this article: "">e2e.ti.com/.../msp430fr5994-can-i-combine-4kb-lea-ram-with-sram-into-a-single-8kb-block-of-ram". I was able to extend the RAM area. In the properties of the project in CodeComposerStudio, I entered the following in Build/MSP430-compiler/Predefined Simbols: MSP_DISABLE_LEA. Unfortunately, this did not help. Do I have to switch off the LEA directly? How does that work exactly?

Best Reagards
Hardy

  • Hi Hardy,

    While the LEA module is running, the LEA data operations are performed on a shared 4KB of RAM out of the 8KB of total RAM

    Some materials of LEA is in below

    Low-Energy Accelerator (LEA) Commands Reference Guide

    Low-Energy Accelerator (LEA) Registers Reference Guide

    Low-Energy Accelerator (LEA) Common Parameter Blocks Reference Guide

    If you don't use LEA RAM. You could define the RAM length and delete the define of LEA_RAM in .CMD file. 

  • Hi Allen,

    thank you for the quick reply. Unfortunately, it doesn't really help. I'll try to describe the problem in more detail using an example. The steps are also shown in the attached video. Deactivating the LEA in the project settings is shown in the photo. Is the deactivation done correctly?

    In the example, the stack of the project is located in the upper 4 KB segment of the RAM. Four successive write operations with identical machine instructions in the stack are shown, which are carried out for parameter transfer in a function call. The first registers of the LEA can also be seen. It can be seen that the first and the 3rd write-oppation work. After the 2nd and 4th write operation, only the hi part of the 32-bit value can be seen on the stack. The memory cells to which the LO part belongs are unchanged. The sub-programme therefore receives incorrect values. Can you help me? What can I do to make it work?

    Greatings
    Hardy

  • Hi Hardy,

    You could try to change the RAM length in  .CMD file and delete related LEA RAM information.

  • Hi Allen,

    yes, I did that. In my post above I wrote that it still doesn't work. The Lo part of the pointers is sometimes not written on the stack. Note on the video: You can see at one point that 16 times 0x11 are written to the stack. I do this by hand to show that through the MOVA commands sometimes only the Hi part (0x0000) is written and the Lo part remains unchanged. But the Lo part is important here.

    Greating
    Hardy

  • Hi Hardy,

    Could you post your code?

  • Hi Allen,
    thanks for your help.
    The programme is very long. I can't post the complete code. I will reduce the post to the part that shows the error. It is the call to a subroutine. The subroutine is passed 4 pointers. The pointers are stored on the stack. Putting them on the stack does not work. It is easiest to see in the assembler code. I describe the memory and the register contents.

    1:  966    void savePosAndVelInSensors(float *lon, float *lat, unsigned int *alt, unsigned char *vel){
            savePosAndVelInSensors():   // this is the head of the function
    2: 042864:   00B1 0010           SUBA    #0x00010,SP   // SP: 0x003BD0
    3: 042868:   0F71 000C           MOVA    R15,0x000c(SP)   // SP: 0x003BC0, R15: 0x002A60
    4: 04286c:   0E71 0008           MOVA    R14,0x0008(SP)   // R14: 0x003BDE
    5: 042870:   0D71 0004           MOVA    R13,0x0004(SP)   // R13: 0x003BDA
    6: 042874:   0C71 0000           MOVA    R12,0x0000(SP)   // R12: 0x003BD6
    7:  968        itoha((uint8_t*)lon,(uint8_t*)&sensors.lon[1],4);   // this is the first line inner the function...
    8: 042878:   008D 5383           MOVA    #0x05383,R13

    After executing line 2, I write to memory by hand:

    0x003BC0: 11    11    11    11    11    11    11    11    11    11    11    11    11    11    11    11
    The memory (stack) changes as follows:
    After line 3:
    0x003BC0: 11    11    11    11    11    11    11    11    11    11    11    11    11    11    00    00

    After line 4:
    0x003BC0: 11    11    11    11    11    11    11    11    11    11    00    00    11    11    00    00

    After line 5:
    0x003BC0: 11    11    11    11    DA    3B    00    00    11    11    00    00    11    11    00    00

    After line 6:
    0x003BC0: 11    11    00    00    DA    3B    00    00    11    11    00    00    11    11    00    00

    It can be seen that in this attempt the contents of registers 15, 14 and 12 do not arrive completely on the stack. Only the content of register 13 is completely written to the stack. In other attempts, other registers are written and others are not.

    The content of LEACNF0 is 0x00000001. The programme section is not interrupted by an interrupt. I can show the phenomenon in a video conference.

    Is it possible to check what the content of the DMA destination address is at that particular time? Is it possible that a DMA write to another RAM area is preventing the CPU from writing?

    I can work around the problem by not passing the parameters through the stack. But then I don't know if the programme is unstable in other places. That's why I think finding the cause is important.

    Greatigs
    Hardy

  • Hi Allen,
    thanks for your help.
    The programme is very long. I can't post the complete code. I will reduce the post to the part that shows the error. It is the call to a subroutine. The subroutine is passed 4 pointers. The pointers are stored on the stack. Putting them on the stack does not work. It is easiest to see in the assembler code. I describe the memory and the register contents.

    1:  966    void savePosAndVelInSensors(float *lon, float *lat, unsigned int *alt, unsigned char *vel){
            savePosAndVelInSensors():   // this is the head of the function
    2: 042864:   00B1 0010           SUBA    #0x00010,SP   // SP: 0x003BD0
    3: 042868:   0F71 000C           MOVA    R15,0x000c(SP)   // SP: 0x003BC0, R15: 0x002A60
    4: 04286c:   0E71 0008           MOVA    R14,0x0008(SP)   // R14: 0x003BDE
    5: 042870:   0D71 0004           MOVA    R13,0x0004(SP)   // R13: 0x003BDA
    6: 042874:   0C71 0000           MOVA    R12,0x0000(SP)   // R12: 0x003BD6
    7:  968        itoha((uint8_t*)lon,(uint8_t*)&sensors.lon[1],4);   // this is the first line inner the function...
    8: 042878:   008D 5383           MOVA    #0x05383,R13

    After executing line 2, I write to memory by hand:

    0x003BC0: 11    11    11    11    11    11    11    11    11    11    11    11    11    11    11    11
    The memory (stack) changes as follows:
    After line 3:
    0x003BC0: 11    11    11    11    11    11    11    11    11    11    11    11    11    11    00    00

    After line 4:
    0x003BC0: 11    11    11    11    11    11    11    11    11    11    00    00    11    11    00    00

    After line 5:
    0x003BC0: 11    11    11    11    DA    3B    00    00    11    11    00    00    11    11    00    00

    After line 6:
    0x003BC0: 11    11    00    00    DA    3B    00    00    11    11    00    00    11    11    00    00

    It can be seen that in this attempt the contents of registers 15, 14 and 12 do not arrive completely on the stack. Only the content of register 13 is completely written to the stack. In other attempts, other registers are written and others are not.

    The content of LEACNF0 is 0x00000001. The programme section is not interrupted by an interrupt. I can show the phenomenon in a video conference.

    Is it possible to check what the content of the DMA destination address is at that particular time? Is it possible that a DMA write to another RAM area is preventing the CPU from writing?

    I can work around the problem by not passing the parameters through the stack. But then I don't know if the programme is unstable in other places. That's why I think finding the cause is important.

    edit:

    I have noticed a connection with a DMA channel. This is triggered by a UART and writes the received byte into another RAM area. This writing works. If I disable this controller during the execution of lines 3, 4, 5 and 6 above, the execution of the MOVA commands of lines 3, 4, 5 and 6 will work.
    However, the DMA operation is needed.
    How can I ensure that the stack operations work without errors?

    Greatigs
    Hardy

  • Hi Hardy

    Modify the .cmd file like this extend the RAM to 8K and  remove all the LEA information

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    /******************************************************************************
    *
    * Copyright (C) 2012 - 2020 Texas Instruments Incorporated - http://www.ti.com/
    *
    * Redistribution and use in source and binary forms, with or without
    * modification, are permitted provided that the following conditions
    * are met:
    *
    * Redistributions of source code must retain the above copyright
    * notice, this list of conditions and the following disclaimer.
    *
    * Redistributions in binary form must reproduce the above copyright
    * notice, this list of conditions and the following disclaimer in the
    * documentation and/or other materials provided with the
    * distribution.
    *
    * Neither the name of Texas Instruments Incorporated nor the names of
    * its contributors may be used to endorse or promote products derived
    * from this software without specific prior written permission.
    *
    * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Test by defining a large array, you could see the .map file after building. The RAM is 8K and used 1fe2 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    ******************************************************************************
    MSP430 Linker PC v20.2.0
    ******************************************************************************
    >> Linked Wed Sep 15 19:30:39 2021
    OUTPUT FILE NAME: <MSP430FR5994.out>
    ENTRY POINT SYMBOL: "_c_int00_noargs_mpu" address: 00004000
    MEMORY CONFIGURATION
    name origin length used unused attr fill
    ---------------------- -------- --------- -------- -------- ---- --------
    TINYRAM 0000000a 00000016 00000000 00000016 RWIX
    BSL 00001000 00000800 00000000 00000800 RWIX
    INFOD 00001800 00000080 00000000 00000080 RWIX
    INFOC 00001880 00000080 00000000 00000080 RWIX
    INFOB 00001900 00000080 00000000 00000080 RWIX
    INFOA 00001980 00000080 00000000 00000080 RWIX
    RAM 00001c00 00002000 00001fe2 0000001e RWIX
    FRAM 00004000 0000bf80 00000042 0000bf3e RWIX
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    You could have a try on it. If you have other problem, you could submit a new ticket.

  • Hi Allen,

    I made the recommended settings before the test. The result was the use of the upper address range in RAM by the linker. This can be seen in the displayed values of the stack pointer and the registers 12, 13 and 14 in my last post. The problem is: Why is only the HI part of the registers written to RAM? Why does this only happen sometimes and not with every write operation within the same c-code line?

    As requested, I will open a new ticket about this.

    Greatings
    Hardy

  • Hi Hardy,

    I will close this ticket.

    Thanks.

  • My last test showed that the problem is due to the incorrect execution of a machine command under certain conditions. It also occurs in the lower RAM range. So it can't be the LEA. It is ok if you close this ticket.

  • Hi Hardy,

    Thanks for using MSP430 and E2E.

**Attention** This is a public forum