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.

CCS/MSP430FR5739: After CCS update long running project cannot load with MSP-FET emulator "Error connecting to the target. Unknown device."

Part Number: MSP430FR5739
Other Parts Discussed in Thread: MSP-FET, MSP-GANG

Tool/software: Code Composer Studio

Our IOT project was completed a few years back.  This year, we went back to the code to change one line with the protocol for our new server.  The code compiles without error and looks like it is loading into our device.  But then it stops and says "Error connecting to the target. Unknown device". The first time I tried the MSP-FET emulator required a software update.  I thought perhaps the update failed, so I tried loading a very simple program built from scratch and it runs without a problem.  Next I thought something might have changed because of a CCS update (I've had this problems like this in the past).  So I rebuilt the project from scratch starting from a blank Grace project for this chip.  It also compiles without a problem, but encounters the same error.  We have many devices with the same hardware and have tried several of them with the same results.  We're baffled.  It doesn't seem to be the code (it has been working for years).  It doesn't seem to be the hardware (it has also been working for years).  It isn't the emulator.  My colleague tried using a different emulator and hardware and the same thing happened.   All the JTAG connections are to spec (and they were not a problem)  we are using a 33K pull-up and 1nF  pull down on the RST line, which worked fine in the past.  What could be causing this problem?

  • Hello Samuel,
    could you please let us know the CCS version you're using, and if possible the version you have been using at the time, when this project has been created ans successfully debugged in the past? Many thanks in advance.

    Best regards
    Peter
  • Hello Samuel,
    could you please in addition try to import from the TI Resource Explorer within CCS any of the C-based code examples, e.g. the first one, and try downloading it to the FR5739, and let me know about the outcome? Many thanks in advance.

    Best regards
    Peter
  • Yes, that is what I tried already.  I took the LED blink example and modified it so it wouldn't mess up our hardware.  It loaded fine.  I was able to single step a few steps and didn't go beyond that because I confirmed that it had loaded...

  • I'm using Version: 6.1.1.00022 . I have let my computer update whenever I was notified and I haven't kept track of what version I was using in the past. I last compiled this project about a year ago, and it was first created about 4 years ago.

    I thought something might have changed with the new CCS version so what I did (and has worked in the past when I couldn't get things to compile after updates) was to create a new Grace project from scratch, copy over my code, and copied all the settings for Grace. The program compiled without a problem, but I still got the same error.
  • Hi Samuel,
    many thanks for the additional information. One question on the Grace usage. Why have you tried setting up from scratch your IoT project based on Grace? Have you done that too with the original version, which was functional before?
    Would it be possible to try setting up the project from scratch without Grace?
    The 6x CCS version is quite an old one. We're currently on CCS9. Some things are not checked back when updating to significantly higher versions. Maybe something broke on one of those updates. I need to check back with our tools colleagues.
    Would it be an option migrating to a higher version of CCS? I know testing a complex application is a pain.
    In general I would recommend creating an image of a project, upon production release. This does prevent running into the issue of potential IDE update impacts.

    Best regards
    Peter
  • Yes, the original project also used grace. I was not aware that I was still in an old version. I thought my automatic updates brought me to newer versions. We are not a development house, our project was a one-time thing for environmental monitoring. So I don't have any experience with CCS other than this project. Which is to say that I don't know how hard it will be to migrate to the newer CCS. Is there any reason why I can't keep it in grace and just copy the code and settings?

    I'm not totally sure I understand what you mean by creating images, but we recompile the code for every new device to embed IDs, and have to recompile it if our server changes and for different telecoms. We didn't have enough code space to create a run-time system to do this.
  • Thanks for your help. Importing into CCS9 fixed the problem of getting the code to load. Now I just have to figure out why it doesn't work. It seems to go to permanent sleep after about a second. Is there anything I should know about settings that need to be changed to migrate code from CCS6 to CCS9? Strange that code that used to work now doesn't.
  • Hi Samuel,
    happy to hear the migration to CCS9 solved the problem.
    The CCS environment is a complex system consisting of many components, not really visible to you as a user. We try to maintain the compatibility when updating those components, but especially with older versions it gets more and more difficult.
    If everything works as intended, there should be nothing to change.
    The update procedure in CCS is from top level point of view as follows: If you have a CCSx version installed, you get all the updates for this CCSx, like in you case with CCS6.x. You got all the updates from CCS6.0 to whatever the highest version of CCS6.x was. But e.g. the migration from CCS6.x to CCS7.x does not happen by updates. You need to install another instance of CCS.
    On your side with the CCS6.x updates some of the components related to your original project got into a version mismatch probably. That's the most probable root cause for such issues.

    To explore a bit more in detail on the "image" topic, no matter how you create your code, whether it is assembler, C-Code, C++ etc. in the end the IDE creates the necessary machine code, which is programmed into the device, as this is the only code the microcontroller understands. Usually, when working with an IDE like the CCS, you do not look into this code and do not generate the so called image file, which is the reflection of this machine code. But if you want you can see it, e.g. by opening the pull-down menu "View>>Disassembly". There you can see, e.g. in case you have written the code in C, the C instructions, the translation to assembler, and the final machine code.
    The image file is sort of just the machine code, including some other instructions, or markers, dependent on the format, where accross the industry some different standards have been established, like Intel HEX, TI .txt and others. This is about how the machine code information is stored in the respective file, including information about the code placement in the program memory of the MCU.
    This image file is not generated by default, as not needed by the IDE, which uses it's own format.
    To enable the creation of such an image file, one has to go to the project properties >> MSP430 HEX Utility >> enable MSP430 Hex Utility >> Output Format Options >> click on the Output Format selection on the right >> select desired format e.g. TI-TXT.
    The advantage of such a file is, it does not change anymore with IDE or Compiler updates. The disadvantage is, in case you want to change some values, like in your case IDs, you would need to know the location of the IDs and change the file manually, which is pretty risky, as if you make a mistake, there is no compile check or anything that would tell you. The other option would be using this image file in combination with a professional production programmer, like our MSP-GANG, which supports features like serialization, means updating some IDs with each and every programming cycle to support recognition of the devices by a unique ID. If you want to learn more about this, please visit the landing page of our Gang programmer www.ti.com/.../msp-gang and the related User's Guide.

    Best regards
    Peter
  • It solved one problem, but created at least one new one. It looks like Grace is no longer available in CCS9. Correct? So to figure out what is not working I have to sort through all the machine generated code and figure out what went wrong? Am I correct in thinking that the problem is with the machine generated code because the code ran without a problem in CCS6 and now freezes in CCS9?
  • Hi Samuel,
    GRACE is no longer supported since quite a while. I never have used it myself, but as far as I remember it has been intended to do the module configurations and initialization, or better to say create the necessary code for these based on a graphical interface.
    Of course wrong or incomplete module configurations and initialization might be the root cause, but it sounded like your project is a quite complex one, so there might be other reasons too.
    The point with the initialization could be checked, if you know the necessary initializations, proven from the previously working project versions, "dumping" the control register settings of those, and checking by debugging with the newly generated one, by halting the code execution after initialization, and checking the control registers of all used modules, whether they are set accordingly.
    Then based on the results go further steps.

    Best regards
    Peter
  • Thanks for the reply.  Yes,  I did think of looking at the control registers to see what has changed, but there is one problem  How do I look at the registers in the former code if I can no long assemble and load the former code?  Is there some way to debug without loading code?  Perhaps there is, but I've never done that before.  If there isn't, then I'm in a circular problem (like the old song "There's a hole in the bucket"). https://www.youtube.com/watch?v=yD-ffhvefsw

    I can't assemble the old code what should I do?

    The solution is to run the new CCS.

    But the code in the new CCS doesn't run, How do I fix it?

    The solution is to look and see what changed in the control registers. 

    But How do I look at the control registers in the old code?

    The solution is to debug the old code.

    But how do I debug the old code. 

    The solution is to assemble it.

    But I can't assemble the old code....  

  • Hi Samuel,
    maybe I misunderstood one of your previous posts.

    You wrote at one point:
    "Thanks for your help. Importing into CCS9 fixed the problem of getting the code to load. Now I just have to figure out why it doesn't work. It seems to go to permanent sleep after about a second. Is there anything I should know about settings that need to be changed to migrate code from CCS6 to CCS9? Strange that code that used to work now doesn't."

    So I understood you're able to compile and download the code with the new CCS version. If that's the case, on starting the debugger and downloading the code, the code execution should halt on the first code line of main.
    Further I understood the code execution freezes after a while? Now at that point you could try to pause the code execution, with the pause button and if that works check the module settings, whether they are as you expect them to be.
    If that isn't the case, but the code can be downloaded and the MSP halts at the first code line of main, instead of releasing the device to free run, you could start stepping through the code and go through the initialization sequences, and see whether the modules get initialized as you expect.

    If my understanding of your previous post is completely wrong, then please clarify what the status exactly is with the new CCS9. Many thanks in advance.

    Best regards
    Peter
  • Hi Peter,  I think we are on the same page.  I thought you were suggesting that I compare the registers with how they were previously as a simpler way to figure out what was wrong rather than a debugging process solely looking at the new code that fails.  Without the old program to compare, I have to actually understand what every register does and how every bit is set instead of just looking for what changed.  So I see now that I should never had worked with Grace to begin with, that any initial time savings I had in being able to write code has been undone and then some now. by keeping me ignorant...

  • Hi Samuel,
    my apologies for the inconvenience we've generated by discontinuing the support of Grace. That's the downside of these code generation support tools, when they're being discontinued.
    Do you have the date, when the last functional code has been created and if possible the map file information from that compile instance? I don't want to raise expectations or make promises, but the other thing we could potentially try is getting you back to that CCS environment version, to support you in regaining the functionality of your project. As indicated, I am not sure, whether we will be able to do that, but if you have the above information, we could give it a try.

    Best regards
    Peter
  • Hi Samuel,
    I assume you're trying to find your way with the given recommendations. Thus I am closing the thread. In case you still need further support on this, you can still re-open it by posting.

    Best regards
    Peter

**Attention** This is a public forum