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

MSP430FR5969: MSP-FET430UIF is already in use

MSP430FR5969: More MSP-FET430UIF is already in use problems...

Peter Hallenbeck
Intellectual 540 points
Part Number: MSP430FR5969
Other Parts Discussed in Thread: MSP-FET430UIF, MSP430FR2355, UNIFLASH, MSP-FET, MSP430FR2155, TPS55288

There is a lot of people who have had this problem.   I used CCS Version: 10.4.0.00006 and the launch pad board to program the part in the circuit board about 6 months ago. I'm making a change, and with the exact same hardware setup I get the dreaded "MSP-FET430UIF is already in use" error.

I've yet to see an explanation as to what this really means. If this is already in use, how can you figure out what is using it and shut it down ?

I can see the MSP Debug Interface on a com port in the Device Manger in Windows 10.

I have re-booted windows, tried plugging and unplugging the launch pad, moved to a different USB port.

Still no luck. Is there any way to actually diagnose what is wrong, or is this just a game of power cycling, rebooting, reloading software and trying stuff ?

TIA

  • 0
    Intellectual 540 points

    I specifiedthe processor as a MSP430FR2355 but because I did a "Ask a related question" that got over-written....

    Just more info on the exact set-up.

    Update: I took a new Launch Pad for the 430FR2355 and tried it. It got the "You must update your firmware" error. Last time I tried that it bricked the launch pad. Tried it on this new launch pad, got error saying I had to update the firmware. Clicked the OK,  now I get the error "MSP430: GEL: Target must be connected before calling the function" and I think this new out of the box launch pad is now bricked. Can't do anything with it.

    I just ordered 3 more since it seems to be so easy to destroy them doing an update of the firmware, which has to happen before you can do anything else.

    So I'm back to just what does this "MSP-FET430UIF is already in use" mean ?  With no hardware or software changes, the setup that worked 6 months ago doesn't work now. Is there some hidden lock file that makes CCS studio think some other device is in use? So hard to believe that a brand new out of the box launch pad device, with CCS fully update to 10.4.0.00006 (what was downloaded when I did an update today), can not connect to what use to work, and can not update the firmware on the launch pad without bricking the launch pad.

    Please explain the exact mechanism that causes this error.

  • 0 in reply to Peter Hallenbeck
    TI__Genius 11320 points

    Hi Peter,

    The common cause to this is some resource on the computer side being used/stuck which is causing conflicts. Our latest Code Composer version is version 12, I would suggest to update to that. The most common fixes have been to reinstall the drivers or use a different port. Have you tried to use the device on a different computer? This could help isolate if it is really an issue with the FET or if there is some resource in CCS + Windows that is causing this error. Another check would be to use the CCS Cloud to program as it will update the Launchpads on board FET.

    Regards,

    Luke

  • 0 in reply to Luke Ledbetter
    Intellectual 540 points

    Can you explain exactly what this error means? Is this generator on the Windows machine, or as a result of interacting with the launch pad device ?

    How do you recover from a error when trying to update the firmware on a new launch pad device ?

    Why would this pop up when there have been zero changes to software or hardware?

    I've done all the re-boots of the PC, tried different USB ports, power cycled the launch pad, all to no avail. I'll download V12 and try it, but it is very frustrating that in all the posts on this, there has never been a concise explanation of what is causing the error.

  • 0 in reply to Peter Hallenbeck
    TI__Genius 11320 points

    The error could happen for various reasons, which is why each post has different solutions for them. The main factor is a connection issue between the PC, CCS, and the FET. Without being able to isolate any of those it is difficult to tell you what is the cause for your situation.

    You could program using Uniflash, this will also update the FET and can isolate if the issue is with CCS. If you get the same error then CCS shouldn't be the issue, it would either be the FET or the PC. Next if the issue persists on a different PC then it can point to an issue with the FET.

    Regards,

    Luke

  • 0 in reply to Luke Ledbetter
    Intellectual 540 points

    Running version 12, no change. Still get the error.

    I don't have another machine to try this with. It sounds like the software really has no way of knowing or giving better error information. I come back to "Why did it work, and then 6 months later with the same set-up it did not work"?

    Since the new launch pad got bricked when I clicked on the update firmware, what is the next step there? I tend to doubt the PC since it found the new launch pad, and was able to determine the firmware was out of date. So clearly the PC can talk to a the launch pad over the USB.

    How about this: a path to isolate where the problem is ?  If the challange is figuring out if this is the PC, CCS or the launch pat (FET) then what steps should be done to debug that ?

    When the bricked launch pad fails when I attempt to load a program, I get a "Target must be connected before calling the function" error. Another "boy this could error message could be so much better moment" for sure....

    So lets focus on how to get a stand alone launch pad firmware updated, so I can test and debug with that, a know entity.

    update:   I loaded UniFlash, and it give the same error:   MSP-FET430UIF is already in use

    We're back to square one

    More Update:   I changed out the launch pad for the one that had the bad firmware update. Uniflash could talk to the uP on my PCB. But it does not start the program (the box was checked). Additionally, V12 of CCS can't see or do anything with the target. If I try to load, I get the  "Target must be connected before calling the function" error again. I can not reset or start or create breakpoints. so while it  looks like Unifllash can program, CSS can't do anything with the target device.

    I can not load or debug anything. CCS can't do read or write the target device.

    Weds. Morning update:   Power cycled everything, re-booted PC.  Now CCS can program and start the target. Next steps are checking all the config settings. Will advise as the day goes on.  Still need to figure out how to update the firmware on the "old" launch pad device using Uniflash, while I have 3 more on the way it would be nice to know why things are happy and unhappy and not just reset/power cycle until things work.

    The error messages from CCS need a lot of work. They could provide so much more information saving both end users and TI support a lot of time.

  • 0 in reply to Peter Hallenbeck
    TI__Genius 11320 points

    Hi Peter,

    I was looking around at other threads and saw you had the same issue a couple years ago (I think you mentioned it in your first post here as well). I'll talk to our tools team about the message of "MSP-FET is already in use" and see if there is a way to narrow down the cause further (maybe if they can tell if the FET is being used or just the port itself). Just out of curiosity is this the same machine that you used when you had this issue a couple years ago? Also did you perform a windows update before this issue occurred (I'm wondering if a windows update caused the drivers to behave abnormally)? 

    It is possible that during one of your reboots the peripherals on the PC side involved with the MSP-FET communication was able to get reinitialized which solved your connection issue. Unless power was cut off during the updates the Launchpads shouldn't get bricked from an update, so all the devices you have should work.

    Regards,

    Luke

  • 0 in reply to Luke Ledbetter
    Intellectual 540 points

    This is the same machine I used 2 years ago. I also used this machine and the "original" launchpad 6 months ago with no problems.

    Based on "playing" with things in various states of malfunction, it seems that error information that could be more useful would look like this:

    1) If CCS can't find an entry in the ports labeled "MSP Debug Interface", then the error is "No debug interface found found in the available COM ports".

    2) If the port is found, then the next step is to try to open/own the serial port. It seems now that if this next step fails, this is when you see the misleading "MSP-FET430UIF is already in use" message. So CCS _assumes_ that if it sees the COM port but can't open it, that some other valid FET device is in play. Since PCs are notoriously bad with USB based serial ports, particular if a program doesn't release a port it owns before it terminates, an error saying "Can not open the 'MSP Debug Interface' on ComX" would be much more descriptive of the problem. Savvy (and bruised) Windows users will realize it's time for a re-boot.

      At this point, all subsequent error messages should also include the CCS version number and Windows version. This lets people who seek help just copy-paste the error message (or take a screen shot) which streamlines the help process by reducing a cycle of "What version(s) are you using?

    3) If the port was opened, but communications with the debug interface had some issues, then a message like "Open ComX but device does not appear to be responding" would indicate an issue with the Debug Interface. This message should also include the baud rate of the serial connection.

    4)   If you make it this far, CSS is now communicating with the Debug Interface on a device. Presumably devices can provide some identity to CCS so that it can be determined if the device is capable of programming the target system based on CCS settings. In my case, that would be programming a MSP430FR2155. If the device were not capable of programing the target, an error message to that effect could be displayed.

       If you make it this far, then presumably most other issues would be at the CCS end.

      One more detail about my set-up:  I'm using the MSP430FR2355 (the one with extra analog support) launch pad to program the MSP420FR2155 that is on a power supply board which is the DUT. I have the uP on the launch pad disconnected by removing the jumpers/headers. I then take GND, SBWTCK and SBWTDIO lines over to a 3 pin header on the power supply to program the uP. As such, the launch pad is an inexpensive programmer that works just fine. But as we've seen here, it helps to have a few as a backup.

      I still need to go back and see why the Launch Pad I used 6 months ago got unhappy. At least I'm upgraded to V12 of CCS, albeit the hard way.

      Gratuittous picture of the power supply PCB enclosed. Note that all the semis are TI parts. At 50 watts out on either supply, the efficiency is 96%. Many of the supplies voltages and parameters are set using the serial port connected to a terminal. The FR2155 also provides power-up timing, can boot or take down the server, logs faults, deals with temperature based alarms. All voltages and currents are monitored. The FRAM allows for log data to be persistent across boots, and can be viewed with a terminal as a sort of "black box". The serial port to the mother board provides a JSON data object with all the current settings and measurements for the board, including the time until the system will be taken down (if in effect). The impact of a MPS430FR2155 and the TPS55288 with it's I2C configurability does a good job of integrating power system control onto the power supply board, and integrating all that  into the mobile server operations. The boost-buck nature means that even if the vehicle is cranked and the battery goes down to 6 volts for 50 mS or so the + 12 to the server stays up even though it's drawing 50 watts. 4 layer PCB, 2 Oz. copper.

      Recently I had to deal with a use case that would be pretty much impossible for a typical boost-buck supply. I can re-configure the TPS55288 so that the odd load presented by a new device can be accommodated. This is the Swiss army knife of power supplies for use in the mobile environment, thanks to the power supply and processor chips. The software change prompting my current efforts lets me add one more end user configurable feature (adjust the slew rate for voltage change).

      I'll mark this as closed, resolved due to an unknown sequence of events and hope things are stable for another 6 months.

**Attention** This is a public forum