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.

  • Resolved

mspdebug v0.23 dislikes FRAM MCU?

Expert 1050 points

Replies: 3

Views: 985

I work for some time with msp430fr57xx family of FRAM MCUs. My OS is Linux Mint.
Hardware programmer is eZ430 board. For programming of a target MCU I use MSPDEBUG (v.0.22) with a simple command line:

mspdebug rf2500 "prog <file>.elf"

The command works well either from Terminal window or as a Tool of Code::Blocks and Code Compose Studio.

Then I tried to launch hardware GDB debug and had to make MSPDEBUG v.0.23 from source. After some amount of experiments I switched to a msp430g2231 as a target MCU (to make all things easier)...
But now I returned to FRAM MCU and as it seems - MSPDEBUG refuses to program my chips!

How it is looked:

1) The connect is OK, I try 

mspdebug rf2500

... here I get the messages about the connection - and the MCU type is shown right...

(mspdebug)

2) At this point I can put mspdebug commands, such as run, md and so on. As you see, connect is good.

3) But the command prog or just erase cannot be executed. I get various messages, such as 

rf2500: can't receive data: Resource temporarily unavailable
fet: erase command failed
fet: FET returned error code 14 (Could not erase device memory)

What can it be? I searched in Google for such messages, but all cases mostly about the connection problems. At StackOverflow there is a close topic, but it is old and the answer is "to get latest mspdebug" :)

Checked another ez430 programmer, changed tardet chips - the same result.

I can return to v.0.22 of MSPDEBUG, but maybe there's another solution.

  • I've got an answer.

    First, I installed MSPDEBUG v.0.22 on another PC. And  I noticed that ERASE or PROG commands are not executed in MSPDEBUG prompt!

    Then I I just read attentively what a good machine tells me: warning: not attempt erase of FRAM device

    That it is! We write FRAM without the preliminary erasing it.

    So I used LOAD command - it works well. And then I performed my usual command of programming - from Terminal window and not from MSPDEBUG prompt:

    msbdebug -n rf2500 "prog <file>"

    It works, of course.

    At last I returned to my main PC with v.0.23 of MSPDEBUG - it works in the same manner. You may:

    1) enter MSBDEBUG and give a LOAD command

    or you may

    2) pass all command during the launch of MSPDEBUG. And (sic!) in the latter case you can use PROG command: msbdebug -n rf2500 "prog <file>"

    Maybe it's sensible to teach MSPDEBUG just to ignore LOAD command and execute PROG command exactly as LOAD. I'll try to raise a topic to Daniel Beer (never did such things before...)

  • In reply to Iurii Vlasenko:

    Iurii,

    Glad you were able to resolve your issue and thanks for the feedback!,

    Regards,
    JH

    Regards,

    JH 

            _____________________________________________________________________


    Search E2E! Your questions may already be answered!

    TI Cloud Tools             MSP Product Page

  • In reply to Jace H:

    The problem is solved in a canonical way. Daniel Beer found a bug in mspdebug v.0.23 and it's fixed in the latest git version.

    So we can use PROG command as well as LOAD - the only difference is that mspdebug issues (on PROG) a warning not attempting erase of FRAM device. The command ERASE raises the same warning without any consequences.

    AFAIK only MSP430FR5726 served as a target in the process. But I think the result is OK for all FRAM MCU.

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.