• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 253 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.

CCSTUDIO: Does the breakpoint function occupy the RAM of the MCU?

Cash Hao11
Mastermind 46745 points
Part Number: CCSTUDIO
Other Parts Discussed in Thread: MSP430FR5994

A customer reported that when their project is almost running out of the FRAM(92%) and RAM(98%) size of the MCU(MSP430FR5994). Some local variables located in the RAM will be distorted when adding a breakpoint in the code to check on other variables. They already set a very large stack size(2800 bytes), however, it does not help this situation. And when the MCU is in free run mode, everything works as expected. So, our question is that does the breakpoint function occupy the the RAM of the MCU? And what else will be used by the breakpoint function? Why using a large stack size can not solve this issue?

Thank you in advanced!

Best regards,

Cash Hao

  • 0
    TI__Guru**** 464971 points

    Hello,

    Cash Hao11 said:
    Some local variables located in the RAM will be distorted when adding a breakpoint in the code to check on other variables.

    What is meant by distorted? The value is corrupt?

    Cash Hao11 said:
    And when the MCU is in free run mode, everything works as expected.

    It could be that halting using breakpoints is impacted real time expected behavior?

    Cash Hao11 said:
    So, our question is that does the breakpoint function occupy the the RAM of the MCU?

    For software breakpoints, it does via opcode replacement. But this would not use up additional RAM. Hardware breakpoints would have no impact since it just monitors the address bus. For more details:

    https://software-dl.ti.com/ccs/esd/documents/users_guide/ccs_debug-main.html#breakpoints

    Cash Hao11 said:
    Why using a large stack size can not solve this issue?

    I do not know. 

    Thanks

    ki

  • 0 in reply to Ki
    TI__Mastermind 46745 points

    Hi ki,

    Yes, the value is corrupt. Here is the story. In free run mode with FRAM usage of 92% and RAM usage of 98%. The MCU works as expected. And the engineer wants to debug the code and add some breakpoints. Then they find out things goes wrong in the debug mode, some variables is corrupt in debug mode and causes the error. 

    If the breakpoint function does not occupy the RAM of the MCU, does the debug function use the RAM? It must have something uses the RAM and corrupt the variables. 

    Best regards,

    Cash Hao

  • 0 in reply to Cash Hao11
    TI__Guru**** 464971 points
    Cash Hao11 said:
    Here is the story. In free run mode with FRAM usage of 92% and RAM usage of 98%. The MCU works as expected. And the engineer wants to debug the code and add some breakpoints. Then they find out things goes wrong in the debug mode, some variables is corrupt in debug mode and causes the error. 

    Once question I have is if during debug they set breakpoints and those breakpoints are hit, then the target would halt and depending on the application, this can impact real-time performance behavior. 

    One check is to set breakpoints that are not triggered and see if the program runs as expected when running in the debugger normally. 

    Cash Hao11 said:
    If the breakpoint function does not occupy the RAM of the MCU, does the debug function use the RAM?

    As mentioned in the link I provided above, hardware breakpoints do not touch RAM. Software breakpoint *do* write to RAM to do the opcode replacement. However, it would not use up *more* RAM. It is just a replacement.

  • 0 in reply to Ki
    TI__Mastermind 46745 points

    Thank you, Ki!

    I will let the customer by set the breakpoints and do not trigger it. And check if the MCU runs normally. 

    Meanwhile, check what type of the breakpoint does the customer use. 

    Best regards,

    Cash Hao