• State Answer Suggested
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1054 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.

Debugger is not working with stack pointer inside of FRAM

Aaron Ewing
Prodigy 130 points
Other Parts Discussed in Thread: MSP430FR5969

Hey, everyone.

I had a problem similar to this on another thread, but it was cleared up.  I am trying to test the capabilities of the FRAM on the TI Microcontrollers and my question is why a debugger in Code Composer would not like the stack pointer inside of FRAM.

I am working with the MSP430FR5969, and I want to place the stack pointer inside of FRAM. The only problem is when I do this (I set the stack pointer by changing the line 

.stack : {} > RAM (HIGH)     to       .stack : {} > FRAM (HIGH)

inside of the Ink_msp430fr5969.cmd file, the debugger will get stuck before the code can be run. I check the memory browser (CCS's way of telling me the value of every single register of the microcontroller) and the stack is inside a valid place of FRAM memory. There is no out of bounds or scope sort of error. It gets stuck on something called __system_pre_init(); I think Code Composer is asking me to tell it what to do because it is not built to handle the stack in FRAM.

Is there something about the CCS's debugger that needs the stack to be inside of SRAM? Is it unable to find it if I move the stack pointer into FRAM?

  • 0
    Guru 25210 points

    According to TI:

    Although FRAM can be used for the stack in a typical application, it is recommended to allocate the stack in the on-chip SRAM. The CPU can always access the SRAM at full-speed with no wait-states independent of the chosen CPU clock frequency (MCLK). Since in most applications the stack is the most frequently accessed memory region, this helps ensure maximum application performance. Likewise, since SRAM memory accesses are even lower power than FRAM write accesses, allocating the stack in SRAM also yields to lower active power consumption numbers. Last but not least, the contents of the stack does not need to be preserved through a power cycle, in most if not all use cases, since the application code performs a cold start and re-initializes the basic C runtime context anyways.

    That being said, you might want to look at Section A.2 (Failure Scenario 1) in the following document: www.ti.com/.../slaa628.pdf

  • 0 in reply to Brian Boorman
    Prodigy 130 points
    Thank you for your reply. I understand all the reasons why it is unnecessary, but I am currently working on something that might be used in Low Earth Orbit eventually. The biggest concern is being hit by ionizing radation and having corrupted data (something that the FRAM is resistant to).

    Back to the question, I checked out section A.2 on the document you attached. It said it applies mainly to controllers of 96KB and 128KB of FRAM. I tried both a 5969 and a 6989 (64kB and 128KB of FRAM, respectfully). Both of them had the same errors. In the case of section A.2 not applying to this situation, do you have any other suggestions?
  • 0
    Mastermind 9055 points

    It should work. But if it doesn't, it could be caused of the memory protection issue. CCS automatically enable MPU and assign range in "Project Options/CCS General/MSP430 MPU".  For me, I always disable both MPU and IPE in the option and set my own setting in the program directly.

    So, I would suggest you to uncheck "Enable Memory Protection Unit (MPU)" and "Enable Intellectual Property Encapsulation (IPE)" before modifying linker command file. Otherwise, the stack or heap memory sections may be protected (set to read only).

**Attention** This is a public forum