• State Resolved
  • Locked Locked
  • Replies 16 replies
  • Answers 1 answer
  • Subscribers 78 subscribers
  • Views 789 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.

Original question:

MSP-FET: Are the new batch of FET's defective.

CCS/MSP-FET: MSP-FET version 2.x fails to write Flash on target processor

Alexander Ribero
Prodigy 170 points
Part Number: MSP-FET
Other Parts Discussed in Thread: TPS3823

Tool/software: Code Composer Studio


Hi,

We purchased 2 MSP-FET flash emulators recently and they are not working with our existing hardware. We have already a MSP-FET from 2015 (SN:151200533) and that one works correctly with our existing hardware. But when we connect the new ones (serial number 1812009B0 and 19010068C), the debuggers don't work: they read the memory, erase, but fail to write flash.

FET-pro430 shows an error when writing the flash "Flash Write Error !!! Segment Address - 0x8000"
The address changes from attempt to attempt, but it is always on the low side (8000, C400, etc)

CCS9 also fails with similar error: MSP430: File Loader: Verification failed: Internal error while writing 0x0C600

It is possible to read back the memory after the failure to write, and it is possible to see that some Flash (up to 0x0C600) was written. But after that location, it it still erased.

I tried with two new MSP-FET, and same behavior.

It is not our hardware because we can program when we use the original MSP-FET. It is existing hardware that has worked for years.

I read a number of threads on the e2e.ti.com support regarding signal integrity issues between the original hardware revision (1.x) and the new revision (2.x) of the MSP-FET.


What I need is the changes to be done in then MSP-FET to fix this issue
See this support thread:

CCS/MSP-FET: new MSP-FET get a message "Unknown device" in spite of MSP-FET430UIF work well. - MSP low...

e2e.ti.com
Part Number: MSP-FET Other Parts Discussed in Thread: MSP430G2433 , Tool/software: Code Composer Studio Hello community, Resentry, I have buy a new MSP-FET. Today


This thread mentions that it is possible to remove some R2 resistor and that will fix the issue.

Do you have more detail into which resistor to remove?

Surely, there has been more people with this issue.

It has been mentioned since 2017
See this as well


MSP-FET: Are the new batch of FET's defective. - MSP low-power microcontroller forum - MSP low-power...

e2e.ti.com
Part Number: MSP-FET Other Parts Discussed in Thread: MSP430F2013 , MSP430G2231 , MSP430G2955 Hello, I recently fried one of my older MSP-FET430UI tools, and


Thanks,

Alex

  • 0
    Prodigy 170 points

    Hi,

    Please note that the JTAG interface is used, and the connections are as indicated in MSP430 Hardware Tools User's Guide (SLAU278ae), Figure 2-1, page 21. In our hardware, C1=2.2nF and R1=47.5Kohm

    There are also some other people that have had issues with the JTAG cable length. See below:

    I used the 8" ribbon cable supplied by TI, a 2" ribbon cable and ~1" single cables connected to the MSP-FET debugger, but neither worked.

    It is not possible to change the target hardware, as it is already designed and in production for several years.

    MSPFlasher 1.3.20 tool also fails to program. See attached log.txt file.

    7875.log.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    Wed Jan 15 17:28:23 2020: * -----/|-------------------------------------------------------------------- *
    Wed Jan 15 17:28:23 2020: * / |__ *
    Wed Jan 15 17:28:23 2020: * /_ / MSP Flasher v1.3.20 *
    Wed Jan 15 17:28:23 2020: * | / *
    Wed Jan 15 17:28:23 2020: * -----|/-------------------------------------------------------------------- *
    Wed Jan 15 17:28:23 2020: *
    Wed Jan 15 17:28:23 2020: * Evaluating triggers...done
    Wed Jan 15 17:28:23 2020: No arguments. Aborting.
    Wed Jan 15 17:28:23 2020: *******************************************************************************
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: Usage: MSP430Flasher [OPTIONS]
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -h / -? Displays usage information (displays this table
    Wed Jan 15 17:28:23 2020: of command line switches)
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -x Displays available exit specifications
    Wed Jan 15 17:28:23 2020: (see tigger -z)
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -i (TI)USB | DETECT | Communication port for the FET debugger. TIUSB
    Wed Jan 15 17:28:23 2020: COMn (Win) | (or USB) is the default. Use COMn (for example,
    Wed Jan 15 17:28:23 2020: ttyACMn (Linux) | COM15) on Windows or ttyACMn(for example,
    Wed Jan 15 17:28:23 2020: usbmodem* (OSX) | ttyACM15) on Linux or usbmodemn (for example,
    Wed Jan 15 17:28:23 2020: HIDn:COMn usbmodem1421) on OS X to choose a debugger
    Wed Jan 15 17:28:23 2020: connected to COM port n. Use HIDn:COMn for
    Wed Jan 15 17:28:23 2020: specific eZ430 tools on Windows. Use -i DETECT to
    Wed Jan 15 17:28:23 2020: execute a FET detection sweep, to display
    Wed Jan 15 17:28:23 2020: detailed information about all connected debug
    Wed Jan 15 17:28:23 2020: tools, and to prompt to select a FET.
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -j fast | medium | slow Configures the MSP Debug Stack to increase or
    Wed Jan 15 17:28:23 2020: decrease the JTAG or SBW frequency of the FET.
    Wed Jan 15 17:28:23 2020: Default = medium
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -n DEVICE_NAME | NO_TARGET (optional for MSP430, required for MSP432)
    Wed Jan 15 17:28:23 2020: The name of the device being accessed (prompt
    Wed Jan 15 17:28:23 2020: if mismatch between found and selected device).
    Wed Jan 15 17:28:23 2020: -n NO_TARGET executes MSP Flasher without
    Wed Jan 15 17:28:23 2020: attempting to connect to a target device
    Wed Jan 15 17:28:23 2020: Choose this option to detect if a certain FET
    Wed Jan 15 17:28:23 2020: is connected or when the FET firmware should be
    Wed Jan 15 17:28:23 2020: updated only.
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -r [filenname,mem_sect] Triggers a read operation in target device
    Wed Jan 15 17:28:23 2020: memory section specified by mem_section. The
    Wed Jan 15 17:28:23 2020: memory content is written to a file specified
    Wed Jan 15 17:28:23 2020: by Filename. Available memory sections are:
    Wed Jan 15 17:28:23 2020: - MAIN = the main memory of the device
    Wed Jan 15 17:28:23 2020: - INFO = info memory (see trigger �u)
    Wed Jan 15 17:28:23 2020: - BSL = bootloader memory (see trigger �b)
    Wed Jan 15 17:28:23 2020: - RAM = random access memory
    Wed Jan 15 17:28:23 2020: - 0x****-0x**** = custom memory section
    Wed Jan 15 17:28:23 2020: Specify .txt as the extension for Filename to
    Wed Jan 15 17:28:23 2020: write data in TI-TXT format, or specify .a43
    Wed Jan 15 17:28:23 2020: (or .hex) to write data in Intel-Hex format.
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -w filenname Triggers a memory write operation. The accepted
    Wed Jan 15 17:28:23 2020: formats are txt (TI-txt) or a43/hex (Intel-hex).
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -v filename (optional) Triggers verification of the target memory against
    Wed Jan 15 17:28:23 2020: a target code file. If -w is used, no argument is
    Wed Jan 15 17:28:23 2020: required. For a stand-alone verify, provide the
    Wed Jan 15 17:28:23 2020: path to a target code file as an argument.
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -u Unlocks protected InfoA memory for writing
    Wed Jan 15 17:28:23 2020: (use only with -w switch)
    Wed Jan 15 17:28:23 2020:
    Wed Jan 15 17:28:23 2020: -b Unlocks protected BSL memory for writing
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Regards,

    Alex

  • 0 in reply to Alexander Ribero
    Prodigy 170 points

    It appears that TI has worked on a MSP-FET firmware solution for this problem. See this discussion:

    MSP-TS430RHA40A: Problem using SBW with MSP-FET - MSP low-power microcontroller forum - MSP low-power...

    e2e.ti.com
    Part Number: MSP-TS430RHA40A Other Parts Discussed in Thread: MSP430FR5739 , MSP-FET , MSP430FR5738 , Hi, I have a weird problem when trying to flash/program

    However, it is not clear if there is a new firmware available yet.

    Alex R.

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alexander,

    could you please try removing the capacitor at the RST pin completely? Many thanks in advance.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi Peter,

    Thanks for your suggestion.

    I removed the 2.2nF capacitor on RTS, but it did not help. The new MSP-FET v2.x still cannot write the flash.

    It appears that TI Employees (Walter Schnoor, Gary Gao) have investigated this issue in the past, and there is even talks about a firmware upgrade for the MSP-FET that would fix the issues.

    CCS/MSP430FR5739: Unable to program using newer debuggers MSP-FET - MSP low-power microcontroller forum...

    e2e.ti.com
    Part Number: MSP430FR5739 Other Parts Discussed in Thread: MSP-TS430RHA40A , MSP-FET , , MSP430FR2433 Tool/software: Code Composer Studio I have three debuggers

    MSP-TS430RHA40A: Problem using SBW with MSP-FET - MSP low-power microcontroller forum - MSP low-power...

    e2e.ti.com
    Part Number: MSP-TS430RHA40A Other Parts Discussed in Thread: MSP430FR5739 , MSP-FET , MSP430FR5738 , Hi, I have a weird problem when trying to flash/program

    Are you aware of these potential solutions? Would you be able to contact these employees and determine the status of the fixes.

    Thanks,

    Regards,

    Alex

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alex,

    the two post you're pointing to are related to the following aspect, but I am not sure, whether this applies to your setup, as you're using JTAG and not Spy-Bi-Wire connection.

    But you can give it a try.

    BTW have you tried programming the device using Spy-Bi-Wire?

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    TI__Genius 17960 points

    Hi Alex,

    any news on your side? Have you been able to resolve the problems?

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi Peter,

    Unfortunately, the issue has not been resolved.

    As recommended by the MSP430 Customer Application Manager, several tests have been executed with less capacitance on the RST line, and removing the 47k pullup resistors on the JTAG lines, reducing the JTAG clock (to 1MHz), but neither of the changes have helped.

    The flash fails to program using either software: MSPFlasher 1.3_20, CCSv9 or FETPro430 v3.5

    The old MSP-FET works correctly on the exact same hardware and it runs with JTAG clock=500Khz.

    Do you have a recommendation on another JTAG debugger that is is compatible with CCSv9 (and older) that can be used to debug MSP430 devices?

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alexander,

    I am sorry for that. If I understood you correctly, you're trying to program the device in your own HW. Do you have a chance to try programming the same code on the same MSP430 derivative, but using a target/socket board?

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    TI__Genius 17960 points

    Hi Alexander,

    in case you need further support on this, please let us know. For now I am closing this thread under the assumption this is not the case.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi,

    After further investigation, it was determined that the MSP-FET v2.x is very sensitive to the hardware layout of the JTAG signals. For one of our custom hardware board, the new MSP-FET v2.x refuses to work (even after removing pull-up resistors, changing RTS capacitor, and reducing cable lengths as much as possible). The only options not tested yet are soldering directly the JTAG wires to the MCU pins directly or changing the PCB layout.

    However, the same MSP-FET 2.x devices work correctly with another set of custom hardware boards that have a different JTAG connection and PCB layout.

    Regards,

    Alex R.

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alex,

    many thanks for the update and information. Would it be possible to share some oscilloscope plots on the JTAG signals, showing the failing communication? Maybe it would give us indications, where the problem is coming from.

    One additional question. Did you test programming with the failing MSP-FET, using an external power supply and connecting the MSP-FET at JTAG connector pin 4, means sense input? Just to see whether it is a supply voltage regulation instability issue.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi Peter,

    I appears that the signal quality (either from JTAG or power supply) is not the issue.

    We did additional testing regarding the MSP-FET v2 with our custom hardware.

    We tried two other different custom hardware boards and they worked fine with the MSP-FET v2.x

    We did a comparison of the differences between these working designs, and the one that doesn’t work, and realized that the design that doesn’t work uses an external watchdog chip (TPS3823) directly connected to the RST pin of the MSP430 device.

    Measurement of the RST signal showed that the external watchdog would try to pull the RST signal low when its timeout expired (~2.5sec), which is expected, as there is no code on the processor to reset the watchdog. The line appeared to be pulled high by the MSP-FET. This appears to prevent the flash write to work.

    As soon as we disable the external watchdog (by disconnecting the signal to the WDI input), the MSP-FET v2.x is able to successfully program the Flash and debug via CCSv9 without any issue, even at the JTAG Fast speed (~9MHz).

    We are quite confused, as the behavior is quite different from the MSP-FET v1.x, which didn’t required to disable the external watchdog, and was able to program flash memory even when the external watchdog pulled the RST line low.

    Do you have any possible explanation of the different behaviors, and if there anything that can be done so that no hardware changes are required on our hardware?

    Thanks,

    Alex

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alex,

    my apologies for the belated response. I have been sick last week. I have been discussing this with our tools colleagues. There are some FW and HW changes comparing the V1.x and v2.x versions. The main aspect related to HW, the drive strength and slopes on the signals are weaker. This would explain why the older one, where the drive strength was higher, is capable to cope with the critical HW of yours, while the new one fails.

    This has been done for CE certification compliance mainly, to reduce the possible electromagnetic emissions.

    More information on the HW implementation of the MSP-FET can be found in the Debugger's User's Guide.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi Peter,

    Thank you for the information.

    We tried with a stronger (less resistance) pullup on the RST and still the new MSP-FET v2.x doesn't work.

    As long as we disable the External Watchdog, the new MSP-FET v2.x works as expected.

    Would you be able to provide a more detailed description of the FW (firmware changes) between MSP-FET v1.x and v2.0? The provided document only provides hardware changes. I'm assuming the MSP-FET v1.x hardware is the same as the MSP-FETU430IF.

    It looks to me that there is some difference in the way the JTAG might be configured inside the MSP430 device when using the MSP-FET v1.x versus v2.x

    When using v1.x, the external RST signal appears to be completely ignored and the External Watchdog doesn't reset the processor

    When using v2.x, the external RST signal appears to dominate and the External Watchdog does reset the processor, preventing the successful memory flashing.

    Regards,

    Alex

  • 0 in reply to Alexander Ribero
    TI__Genius 17960 points

    Hi Alex,

    I am sorry, but the FW of the MSP-FET is not public. I don't think this will change. Up to my information, the v1.x HW is also different from from MSP-FET430UIF. It is closer to v2.x, but with changes due to CE certification requirements, and there are significant changes on the FW side too.

    In terms of the RST pull-up, I'd rather would try higher resistance values, than going to lower ones. Colleagues from tools department have also indicated that using a lower device supply (MSP430 application >> 2.8V--2.5V for programming) might help. Not sure, whether this would be possible in your case.

    Best regards

    Peter

  • 0 in reply to Peter Spevak
    Prodigy 170 points

    Hi Peter,

    Thank you for your help.

    It is clear that the behavior is different between the MSP-FET v1.x and v2.x, not only signal integrity differences, but operation as well (JTAG clock frequency, ability to tolerate an external watchdog circuit, etc).

    Given that MSP-FET v2.x cannot tolerate an external watchdog driving the RTS signal as the v1.x did, and that we cannot change the existing hardware, we'll have to continue using the MSP-FET v1.x or older devices for development, debugging of this hardware platform.

    I'll mark the issue as Resolved, as we understand what the problem is and that there is no other solution available from TI at this time.

    Regards,

    Alex R.

**Attention** This is a public forum