• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 78 subscribers
  • Views 5636 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.

MSP430: Trouble Writing Memory Block at 0xc000 on Page 0 of Length 0x14e: Could not write device memory

Luiz Costa
Prodigy 20 points
Other Parts Discussed in Thread: MSP430G2211

Hi, everyone. I am new in MSP430 programming. However, I installed the CCS4 and had trouble with the license. Then I went back to using the CCS 5 because the tutorial TI offers for the Launchpad, the example Blink_LED, was written for the CCS 5. Well, I overcame the initial problems with the MCU version G2231, G2211, and the G2553 and on both G2231 and G2211 I get the following load problem when all the build is complete:

MSP430: Trouble Writing Memory Block at 0xc000 on Page 0 of Length 0x14e: Could not write device memory

I searched the forum and found another member with that type of problem, but shad no light for my case. kThe individual was talking about lack of uniform/constant success. Unless I didn't understand the message, I am at a loss tight in the beginning of my work.

Please, any help?

  • 0
    Prodigy 20 points

    OK, folks. I found a solution. I don't know if that solves the problem.

    Reasoning:

    When I started CCS 5 the first time, I had built the Blink_LED project initially for the MSP430G2211 target. Then when I realized that the xG2231 was the MCU on the socket I rebuilt the project with a different MCU, MY GUESS is that the MEMORY ENTRY POINT got displaced  to the 0xC000 block as indicated in the *.map configuration file. So when the program loader tried to do its job of transferring the *.out binary to the MCU, it got an error attempting to write to that memory location.

    Solution:

    I closed the project, right clicked and deleted it from the Project Navigation window partitionCCS and with the Windows Explorer, I deleted all the remaining files in the Eclipse workspace. After restarting CCS 5 I repeated the project creation steps for the Blink_LED, rebuilt it, and ran in debug mode without a problem.

    Problem:

    Don't you think CCS should be allow the designer to "clean" everything pertinent when the designer replaces the target MCU. I even used the Project -> right click -> clean option suspecting that kind of a problem, but it just didn't fix it. As a beginner I am taking a chance here, but perhaps CCS could be even programmed to even do this automatically.every time there is a hardware configuration change.

  • 0 in reply to Luiz Costa
    Guru 227245 points

    I think there is a 'clean' option somewhere, but it isn't automatically triggered when the target CPU changes. This is caused by the make-based toolchain: make will forward the new target type to compiler and linker on next build, but won't consider already compiled parts as 'dirty' because the object files are still newer than their code files. The compiler is not called at all for the already compiled parts, and maybe even the linker isn't called if the output file is newer than all source files.
    Sure, one could think that changing the target should clear all object ifles, but teh target is just a setting that is used somewhere later, not a programmatic action.

**Attention** This is a public forum