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.

After several successful debug sessions on an MSP430FR6989, I start getting a "could not erase device memory" error.

Other Parts Discussed in Thread: MSP-TS430PZ100D, MSP430FR6989, MSP-FET

Hello all,

I am using CCS 6.1 and a MSP-TS430PZ100D target board with a MSP430FR6989 in the clamshell. I have been developing a small application, and using the debugging feature to spy memory and such as I manipulate samples from the ADC. Everything was running flawlessly for a while (maybe 10 or so debugging sessions), when all of the sudden I start getting the following error every time I try to debug the program:

MSP430: Trouble Writing Memory Block at 0x4400 on Page 0 of Length 0xe0: Could not erase device memory

MSP430: File Loader: Verification failed: Target failed to write 0x04400

I had not made any significant changes to the program under development...meaning, all I did was change an "int" variable to an "unsigned int" variable. Since this change could not, IMHO, cause the problem with the IDE, I figured I might as well see if anyone else has had this problem and how it was resolved.

  • Hi StephenF,

    Some questions to try to figure out what might be happening:

    What are you using for programming the device - is it the MSP-FET or MSP-FET430UIF tool, or something else?
    Do you get this error when you try to load new code into the device, or at some other time?
    If you try to load a different piece of code, like one of the code examples, do you encounter the same issue?
    Are you able to erase or load the part using something other than CCS, like the Elprotronic Lite Fet-Pro430 software?

    Regards,
    Katie
  • Hello Katie,

    I am using the UIF tool which has been updated to the latest firmware after I installed CCS 6.1. I get the error whenever I load code using the debug button. I have since changed the DCO clock to be 4MHz instead of 8Mhz, and that seems to have corrected the problem. After I switched to 4MHZ, I changed the chip in the clamshell to an unused one, so that I could test. I found that working with a 4MHz DCO clock did not lead to those problems on the new chip, so I figured I'd go back and try to reprogram one of the chips that seemed to have been bricked. It took 3 tries, but the chip that would not program started to accept new software. I have not yet gone back to using 8MHz, but I will be doing so at some point just to see if I can reproduce the problem.

  • StephenF said:

    I am using CCS 6.1 and a MSP-TS430PZ100D target board with a MSP430FR6989 in the clamshell.

    MSP430: Trouble Writing Memory Block at 0x4400 on Page 0 of Length 0xe0: Could not erase device memory

    MSP430: File Loader: Verification failed: Target failed to write 0x04400

    BTW, why FET before writing want to erase FRAM (first write 0FFFFh, and than overwrite it again)?

  • Hi Stephen,

    It sounds like maybe some timing issue btwn your code and the FET tool. Would it be possible for you to provide a piece of code that reproduces the issue, so that we can reproduce on our end? There's likely something in the code that can be changed to make sure this doesn't happen even with 8MHz. If you don't want to post code publicly for some reason, you should be able to send me a private message by clicking on my profile. As a note, one common issue I've seen is that as people's code gets larger, they may have the watchdog time out before the FET tool has control of the device and stops the watchdog. Does your code stop the watchdog at the beginning of your program? Could you also try using __system_pre_init() to stop the watchdog earlier before you ever reach main (there are other threads on this forum that talk about how to do this).

    Regards,
    Katie
  • While that may work, I'd like to use my development set-up as-is. I'd rather find out what is going wrong than working around it. Thanks for your suggestion, though.
  • StephenF,

    Can you provide the code then so that we can reproduce (or a simplified code that also causes the issue)? The test I proposed wasn't merely a workaround - it was meant to be a diagnostic test. If that system_pre_init seemed to fix the issue it would tell us some information about what could be possible causes. However I think the code would be needed for us to be able to diagnose your issue for sure after that.

    Regards,
    Katie
  • Katie,

    I didn't even get as far as testing your suggestion; When I booted up the PC in the morning and tried to reproduce the problem, I could not. I'll send the offending code in a private message, but I'm sure there's nothing there. Best I can gather is that the PC needed rebooting, since that is the only thing that changed. Thanks again for your assistance.

  • Hi Stephen,

    That's quite odd. Please let us know if your issue returns.

    Looking at the code you sent to me, I do see that your code initializes a 128-word array, among some other things. Now, the reason I suggested using the _system_pre_init() to disable the watchdog before main, is that at startup the c-initialization initializes your variables before main (and with EABI it initializes uninitialized variables to 0). When you start having large arrays or a large number of variables to initialize before main, it can start to take some time to execute. The problem here is, that the MSP watchdog timer module comes up running in reset mode at startup (meant as a fail-safe type feature to reset the part if code hangs), and usually you don't stop the watchdog until you can get to the first line of main. So, your watchdog could time out before you ever reach main to stop it if you have a large number of variables/data that needs to get initialized at startup before main. The solution in this case is to use __system_pre_init() (you can find other threads about the specific implementation, like this one) to stop the watchdog - __system_pre_init is a stub function that is called before variable initialization - if you define your own version of it it replaces this function and therefore you can use it to stop the watchdog before the variable initialization.

    So if your issue returns that's one of the first things I'd try (and with the large array in your code that you sent it might be a good idea anyway especially as your program gets larger). The WDT causing fast successive resets like this can make it harder for the FET tool to gain control of the device to do debugging- it becomes a timing issue and so could be intermittent as I think you were seeing. You have to get the new code that stops the watchdog loaded the first time, and then after that the issue should go away (since the existing code in the device runs before the FET takes control of the part, you have to change what that code is before successive loads will work more stably)

    Hope this helps,

    Katie

  • Great information. I always figured the FET tool would prevent WDT resets automatically while programming. I will now start using the __system_pre_init() function on my projects in order to avoid this behavior in the future. good catch.
  • Yes the FET tool does stop the WDT while programming - however it can't stop the watchdog until the tool has been able to take control of the part, and constant resets can interfere with it getting control of the part. So if you see this issue it's going to be when you try to start a debug session. Now, it may give you different error messages depending on when in the process the reset happens and makes it fail, so this makes it a little bit tricky to pin down sometimes. But doing the pre_init helps rule this out from being a cause of the debug issue.
  • Small correction: the WDT isn't on after a reset to catch if code hangs. It is on by default to ensure the CPU is reset if it crashed due to ESD or similar reasons. Which may even happen during boot code. Even right after the previous reset. It ensures the CPU will restart after the watchdog period.
    While many people use the WDT to fix software bugs the hard way, this is not the reason why watchdogs are there (an timer in NMI mode could do the very same). And most people then use the WDT in a way that makes it useless for this purpose too (like triggering the wdt in every loop that could take longer than the watchdog period, even if it could as well take eternally and would need the WDT to bark)

**Attention** This is a public forum