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.

MSP430FR5889 / Communication Problems with JTAG and Spy-By-Wire Interface

Other Parts Discussed in Thread: MSP430FR5889, MSP430F5249, MSP430FR5739, MSP430G2231, MSP430F5418A, MSP-EXP430FR5739, MSP-FET, MSP-FLASHER

Hello,

We would like to program a MSP430FR5889 via JTAG interface and an Elprotronic FlashPro430 programmer.

The JTAG communication always fails with this error message: "The target microcontroller type does not match selection. Selected microcontroller type MSP430FR5889. Target microcontroller type: 5249"

If we change the processor type in the Elprotronic FlashPro430 programmer to MSP430F5249, the JTAG communication initialization is ok,
but erasing memory fails at next.

But the target microcontroller is definitly an type MSP430FR5889 (printed code on housing).

The same effect occurs, if we try to program the microcontroller from IAR embedded workbench.

What is wrong with our programming setup?

Thank you for your help in advance.

With kind regards,

Thomas

  • Hi Thomas,

    How many devices do you have, and how many exhibit this behavior? Also, which versions of FlashPro430 and IAR EW are you using?

    If you can get access to the part (either by overriding the device name mismatch, or through the BSL), can you read the contents of memory at 0x1A05 and 0x1A04? This is where the device ID is stored, and the bytes should be 0x81 and 0xC3 respectively.

    Mike
  • Hi Mike,

    We have too many Microcontrollers of type MSP430FR5889. By MSP430FR5889 IAR (version 6.40) and trying to start Debug using "Elprotonic FlashPro430 Vers. 5.20" one get's the error Message "Fatal Error", if one compile the project then try to program the MSP430FR5889 using Flashpro430 one get's the Error Message "device does not match ... MSP430FR5889 selected but device type 5249 recognized", by continuing the Erase operation does not start.

    As you know MSP430FR5889 JTAG Pins does not match the ones of MSP430F5249, The package is the same "VQN". On the Package MSP430FR5889 is written.

    We had Experiment board for MSP430FR5739, communication with MSP430FR5739 can be established without problems and Debugging with IAR 6.40 works too.

    Khalil

  • Hi Mike,

    In the meantime we prepared a test ciruit with a minimum hardware setup: MSP430FR5889 with a Spy-by-Wire interface
    and the supply voltage only, see attached circuit diagram of the test setup.

    By using the Elprotronic FlashPro430 the result is:
       1. JTAG communication initialisation -> ok
       2. Verifying Security Fuse -> ok
       3. Erasing memory -> failed

    Screenshot from Elprotronic FlashPro430 tool see attached file ErrorMsg.

    Do you have any idea, what is wrong with our setup?

    By the way: The same spy-by-wire interface works fine with e.g. MSP430G2231 or MSP430F5418A or other controllers.

    Thank you for your help in advance.

    With kind regards,

    Thomas

  • Can you try replacing the 2.2nF capacitor on RST to 1nF? 2.2nF is the max, and if there is any additional parasitic capacitance from long traces/wires, it can drive the effective capacitance above 2.2nF.

    Mike
  • Does "internal connection" mean, you have not connected all the power pins outside of the processor?
  • Hi Mike,

    I replaced on two boards the 2.2 nF capacitor against a 1.0 nF and a 560 pF capacitor. Then I checked the communication to the board by JTAG and Spy-by-Wire by using the FlashPro430 adapter. The result was: unfortunately nothing changed, the communication still ends at "erasing memory", see screen shot above.

    Kind regards,

    Thomas

  • Hi Dennis,

    I have some prototype PCBs, where all of the VCC and VSS terminals are connected directly to the supply voltage and ground (as recommended in all application sheets). Further I prepared a handmade board with the minimum hardware to verify the communication problems. This handmade board is in fact connected to VCC and GND by a single wire to terminal 52 and 63 (VCC) and 34 (GND) only. I have checked before, that all VCC and GND terminals are internally connected. The behavior and the error messages of the programmer is for all boards the same. This simple design is not recommended for a reliable application, only for test purposes.

    Kind regards,

    Thomas
  • Tom 29 said:

       1. JTAG communication initialisation -> ok
       2. Verifying Security Fuse -> ok
       3. Erasing memory -> failed

    BTW, what is the reason for using erase on FRAM?

  • Erase means Erasing the nonvolatile Memory (FRAM or Flash). This is working just fine with Experiment Board MSP-EXP430FR5739. It does not seem that Texas-Instruments have a Development/Experiment Board for MSP430FR588x. 

    On the Package it is written MSP430FR5889, TI541C, C8JNG4. Could it be that Texas has a Packaging Error ?

  • In addition to, or instead of, Elprotronic FlashPro430, could you try to use MSP430Flasher?
  • Khalil Hanhan said:

    Erase means Erasing the nonvolatile Memory (FRAM or Flash).

    Flash must be erased (set word to 0FFFFh value) before write.

    There is no need to erase FRAM at all. Except one reason, if the device is locked by program execution, and not able to establish JTAG communication. Then mass erase can be invoke by mailbox system on some FRAM devices.

  • Tom/Khalil,

    In the first post, I think you mentioned that you were using the Elprotronic FlashPro430 Programmer.  Is that this programmer?

    Have you tried using a TI MSP-FET?  There may be subtle difference in hardware (or software) on the emulation side between the two programmers, so I want to make sure the issue is not hardware related.

    Mike

  • Hi Mike,

    Yes, we are using the programmer FlashPro430, the same type as you described in your post.

    We don't have the new TI MSP-FET programmer, but we have checked the communication with the former version MSP-FET430UIF, too. The result was the same (communication fails).

    Kind regards,

    Thomas

  • Thomas,

    We are looking into this, but it might take a little time.  In the meantime, I found a similar post (same thing on another device) that might provide some useful insight.  Particularly the part about trace lengths and wire lengths.  I know you simplified the connections to the device, but you can you provide some additional details on trace and wire lengths on the setup, and if you can shorten these as much as possible (probably easiest to do with the wire connecting the emulator to the board) and test it out, does that change anything.

    Mike

  • Hi Mike,

    I have just read the post, you mentioned in your mail. Until now my Spy-by-Wire interface cable (between programmer and target board) has a length of 30 cm (12 inch) and it works fine with e.g. MSP430G2231 and other controllers from the MSP430 family.

    I have shortend the interface cable now to 14 cm (5.5 inch), but I can't see any difference.

    Kind regards,

    Thomas

  • You can use BSL based on G2 LP to update FRAM code (slaa535 LaunchPad-Based MSP430 UART BSL Interface).
    Maybe your version of msp430 dll is too old and FR5889 is not supported.
  • We have IAR 6.40 and Elprotronic 5.20. They consider and use up-to-date version of msp430 dll.

    Did anyone try the MSP430FR588x ?
  • Khalil,

    What version of the msp430 dll are you using?  If you right click on the MSP430.dll and select Properties, then go to the Details tab, it will tell you the File Version and Product Version.

    Have you tried CCS?  If not, can you download the latest version (available here) and give it a shot?  You don't need to port your entire project, just load up one of the FR5889 Examples from the Resource Explorer.

    Thanks,

    Mike

  • MSP430.dll --> Version 3.5.1.1 used by IAR 6.40 and MSP-Flasher 1.3.7

    IAR-Result : "Fatal Error"

    MSP-Flasher 1.3.7 Result:

    Code Composer ccv6 result:

    ccvs6, IAR and Elprotronic work fine with MSP430F5418A and MSP430FR5739.

    Did anyone try the MSP430FR588x ?

  • I guess this time the reply was posted under

    e2e.ti.com/.../490136
  • Same Results ... Communication Error!
  • Khalil,

    I merged that thread with this one so we only have one thread going. I appreciate the information and additional tests. We will need a little time to run some tests on our end to try to help figure out what is going on.

    Thanks,
    Mike
  • Khalil,

    Again, I apologize this is taking some time while we work on this on our end.  In the meantime, can you connect to the device using the MSPBSL Scripter, and read out part of the TLV (0x1A00 to 0x1A14)?

    Thank you,

    Mike

  • Hi Mike,

    using MSP-FETU430IF, I tried

    script:  "TX_DATA_BLOCK 0x1A00 0x0014 setting.txt"

    the Result:

    @1A00
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    00 00 00 00
    q

    I tried the FRxx_uart.txt exmple:

    Meanwhile, after contacting the support of "Elprotronic" I got a new Software Pre-Release with which programming the MSP430FR5889 is possible, they are still working on a solution for Debugging.

    I think the problem is the MSP-FETU430IF. With ccs6 it is giving the Message "Unknown Device". Can this be fixed?


    Regards,

    Khalil

  • Khalil,

    Are you sure you are using the MSP-FET430UIF (big white box) and not the MSP-FET (slightly smaller black box)?  The MSP-FET supports BSL, but the FET430UIF does not.

    What version of CCS are you using (full version number, e.g. 6.1.0.00104) and what version of the compiler are you using (e.g. TI v4.4.3).  You can find the CCS version by going to Help -> About, and you can find the compiler version in the Project Properties, under the General tab.

    Mike

  • yes, I used MSP-FET430UIF "MSP430 USB-Debug-Interface". We ordered the MSP-FET.

    ccsv6 Version: 6.1.2.00015 , compiler version TI v15.12.0.LTS.

    I guess maybe the MSP430FR5889 is only supported with MSP-FET not by "MSP-FET430UIF".
  • What script/program did you use to read out the contents of memory?

    Both emulators should support the FR5889, so that should not be an issue.

    The reason I'm really dwelling on this is that the MSP-FET430UIF does NOT support BSL (but the MSP-FET does). So I want to make sure the contents of memory you posted was accurate.

    Mike
  • I posted the Debug results using ccsv6 and MSP-FET430UIF on 12 Feb "Error connecting to the device, Unknown Device". Debugging with IAR and MSP-FET430UIF brought "Fatal Error".

    I did not really consider is MSP-FET430UIF support BSL, I used following script:

    MODE FRxx UART 9600 COM22
    TX_BSL_VERSION
    TX_DATA_BLOCK 0x1A00 0x0014 out.txt

    where COM22 is the "MSP-FET430UIF" COM-Port. The results I had were listed in "out.txt", maybe it did not communicate and listed some default results!

    However, since Elprotronic Programmer is working , I guess that there is no problem with the MSP430FR5889.
  • Yes, I think your response was not 100% valid. If the Elprotronic Programmer is working, can you use that to read out the contents of memory between 0x1A00 and 0x1A14? We want to make sure that there is not something else wrong with the device. At the moment, you have the only setup that can generate the failure, so if you would work with us a little bit, we would be grateful. We would like to make sure if something is wrong with CCS or the part, that we identify it and fix it.

    Thanks,
    Mike
  • well, I have now the MSP-FET, communication with MSP430FR5889 and ccs6 and IAR works with this device.

    With the MSP-FET430UIF I can Debug the MSP430F5418A, but not the MSP430FR5889. The memory content from 0x1A00:

    06 06 21 96 c3 81 21 20 08 0a d8 a3 01 09 1d 00 07 00 f8 fe

    Do you think there is a problem with the MSP430FR5889 or maybe the problem is MSP-FET430UIF?

  • Hi Khalil,

    I am glad you got the MSP-FET and it was working fine. Our investigation team would like to take a look at some of the devices that had been failing if you don't mind sending them to us. I will send you an email off the forums to start that discussion.

    Thanks,
    Mike
  • Hi Mike,

    yesterday I got the notification from ccsv6 to update the compiler, after updating to compiler version "TI v15.12.1 LTS". I tried the MSP-FETU430IF with a test program, the MSP-FETU430IF got some new update and then the communication worked also with it, guess with the new compiler some new modifications done.


    At the beginning of this issue, we contacted TI-Distributor "Arrow" and offered to send some devices but unfortunately we got no response till now.  I also contacted TI-Support in Munich and through their websiete/asktexas@ti.com. Their response was:


    "...

    In case you should wish to be supported by the TI engineers in our Asktexas support center, please contact your TI distributor as per below TI statement :

     In order to resolve your inquiry, we would kindly advise you to contact one of our official distributors, who have access to a dedicated technical support team of highly qualified engineers within Texas Instruments, committed to resolve your inquiry with high priority.

    If you are not sure who the preferred Distributor is for your company, please contact your procurement office for assistance.

    Information about official distributors you can find here official distributors or general contact information can be found below:

     Alternatively, we would advise you to utilize the knowledge and experience available on our e2e forum.  Our e2e community is constantly reviewed and managed by TI specialists according to product and is further supported by over 50,000 engineers from around the world sharing their knowledge and experience.  If you are already a member of our e2e community, you can post your question directly on the relevant page on our Engineer to Engineer community.

    If you are not yet a member of our e2e community, please register to myTI

    We hope your experience with TI and our Distribution partners is pleasant and most productive.

     I apologize for not being able to get you in contact with a specialized engineer .

    ... "

    Since things are working after software update of the compiler, the company does not see the necessity of sending the devices.

    Thank you for your support.

**Attention** This is a public forum