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.

Understanding the MSP430 FET

Other Parts Discussed in Thread: MSP430F5529

Hello,

  I recently bought a MSP430F5529 Launchpad, which has a built-in ez-FET, with FET standing for Flash Emulation Tool.  I'm confused on what's happening, when I load my program, is it writing it to the FET and the FET is emulating the flash memory on the MSP430 via JTAG?  If not, what flash is it emulating?  

Also, what is the difference between the release and debug builds?  I expected the debug build to have extra code that enables debugging, but it seems to work on the release build as well, how are they different.  Does the debug build work if programming the chip in production, or does it require the FET to be present to operate?

Finally, if I want to just load the binary onto the chip, how do I do that in CCS without going into the debug mode?

-Mike

  • Mike:

    You should take a look at http://processors.wiki.ti.com/index.php/Getting_Started_with_the_MSP430_LaunchPad_Workshop - it will answer those questions and probably a lot more!

    By the way, the ezFET on the launchpad actually loads the code into the flash memory of the F5529 on the LaunchPad and executes it on that F5529. There really is no difference between release and debug - that is probably covered in the course...

     

  • Todd, thanks for the links.  However,  some of my questions are still unanswered.  For example, I still don't know to just load the code without going into the debugger.  This is the most basic function, it's super obvious on competitor's IDEs, but I just can't find it in CCS.

  • You can use a program like Flash-Pro430 from Elpotronic, for example.
  • ‘Debug’ and ‘Release’ are just names for a certain CCS configuration set, you can delete, create a new one, or rename it. These configuration set defines only how CCS should behave during Build and has no influence on the behavior of the FET. How CCS behaves with the specific configuration you can adjust by selecting the configuration and go to ‘Project\Properties’.

    The main difference between the default Debug and Release configurations is;

    • Debug adds more information to the output file .asm which CCS uses to display when stepping trough the program, the .out file flashed to the MCU stays the same, also the Optimization level is ‘0’.
    • Release omits the additional information for CCS and uses a higher Optimization level which creates a smaller and or faster .out file (program).

    In CCS the only possibility to Flash the program to the MCU is to launch a Debug session (in depended on the selected configuration). CCS will, if needed, (re-)build the project (using the selected configuration) and flashes the program to the MCU, after flashing has finished you can press Terminate and Restart’s your MCU.

    Flashing your software without the use of CCS can be done with the by Dennis purposed program or with MSP430Flasher.

  • I think Leo really answered all of your questions. Though, I thought I'd expand on them a little bit.

    With regards to build configurations, Leo is correct in that the "Release" configuration turns the compiler's code optimizer. While the added efficiency can be valuable for a production system (where you want the smallest code size and/or better performance), optimization often gets in the way of debugging code. Like any good C language optimizer, our compiler will rearrange code - even removing unnecessary parts - in order to produce the most efficient solution it can find. Once again, that's good for efficiency, but it makes it really difficult to debug code line-by-line. Due to this, we usually suggest building your code with a two-step process:

    1. Use the "Debug" build configuration. That is, get your code running without optimization turned on. As part of this process, make sure you debug a set of test cases (some folks call them test vectors) that prove your code is working properly.
       
    2. When you have proven that your code is logically correct - and you need better code efficiency - change to the "Release" build configuration and rebuild your code. Use your earlier validated test-cases to prove your code still works; this is often necessary since you won't be able to step thru your code line-by-line anymore (but you still will be able to set breakpoints at function-level boundaries).

    Whenever you create a new project with Code Composer Studio, it will create the two build configurations (Debug, Release). As Leo mentioned, you can change these configurations or add your own. If you care about getting the best efficiency in your code, I highly recommend reading through the C Compiler Users Guide. (You can find the latest MSP430 Compiler UG at:  

    Flashing the MSP430

    Once again, I like Leo's suggestion of using the MSP430Flasher. It's a command-line utility for programming MSP430 devices. (The MSP430 Workshop Todd referred to has a lab exercise using this tool. You can find it at the end of the CCS chapter.)

    The most popular method, though, is to use CCS to write your program to your MSP430 device's flash memory - just as Todd and Leo stated.

    It's true that most users accomplish loading their code using the "debug" feature - that is, by clicking the Debug toolbar icon. Once the debugger has started and the code has been loaded, you can terminate the debugger and the code will remain in the device's flash memory.

    As an alternative, you can avoid the "Debug" toolbar button (what some folks call the 'easy button) and download your code to the MSP430 using 4 individual steps:

    1. Build your code to make sure your code is properly built. (That is, click the "Hammer" toolbar button.)
    2. "Launch a Debug Session" - which basically tells CCS how to communicate with your processor. To do this, you need to open up the "Target Configurations" window (View > Target Configurations). Then, in this window, navigate to your project and right-click on your project's CCXML file and select "Launch Selected Configuration". This file tells CCS how to talk to your board. (For the MSP430, CCS automatically creates this file for you, if you fill in all the details when creating a new project.)
       
    3. Connect to the target. Now that CCS knows "how" to talk to your board, you need tell it to do so. You'll find this command on the toolbar, or under the "Run" menu. (Run > Connect Target)
       
    4. Finally, now that your board is connected to CCS, you can download your program into flash. Once again, this is found on the "Run" menu.
      (Run > Load > Load Program...)

    Hopefully each of these steps makes sense. But having said that, it's much, much easier to hit the "Debug" toolbar button and let CCS automatically do all four steps for you.

    I hope that between the three of us, we've been able to answer all of your questions.

    Take Care,
    Scott

  • MichaelH said:
     This is the most basic function, it's super obvious on competitor's IDEs, but I just can't find it in CCS

     I don't see more different behaviour from competitor IDE, all have load and debug and also a separate loader to program chip from target code.

     Again as suggested from other you can use utility from Elprotronics or Olimex or from others in the public domain.

     Also if you wish use BSL no hardware at all is required to load code to device, just an USB cable on target.

     Guideline cover this and Launchpad schematic is a good reference.

  • One option that I have found: http://www.elprotronic.com/download.html

    There is an FET-Pro430 Lite version that is free, and it uses the USB FET to download. (I download with MSP-FET430UIF.)

    This is a very quick way to "bypass an IDE" and program device(s).

  • It takes the IDE a moment to reconfigure itself into the debug mode and all my windows change, and sometimes I have a bunch of breakpoints in the code.  I just want to load the program and launch as if it were a production item, and not go into the debug mode.  It's just...uuugggh.   I'm not saying CCS is bad, but my last project required PICs and I felt less frustration with MPLAB X trying to get my chip programmed (MPLAB X has its own quirks, to be sure).

    I tried FET-Pro430, it's in disagreement with CCS about what firmware should be on the FET and both of them want to update the firmware all the time, which is kind of annoying but doesn't seem harmful.  

    Programming seems to take much longer than I've experienced with Microchip PICs,  Does it usually take about 15 seconds to program 16k of flash?

  • Michael:

    Sorry, I saw that elprotronic had already been mentioned. Have you tried using "Release" mode for programming? It seems like that may be an alternative that still allows you to keep your breakpoints and such with "Debug" mode (for debug...)

  • MichaelH said:
    It takes the IDE a moment to reconfigure itself into the debug mode and all my windows change

    CCS has two perspectives named ‘CCS Edit’ and ‘CCS Debug’ and can be selected with the two Tabs in the upper right. ‘CCS Edit’ and ‘CCS Debug’ are just two names and have no influence on the working of CCS. Both perspectives can be fully customized with View’s of your choice.

    When starting a ‘Debug session’ CCS defaults to the ‘CCS Debug’ perspective, but you can change this back to ‘CCS Edit’ anytime without interrupting the Debug session.

    When an active Debug session is going on you can alter/add the source code, build and if wanted Flash the newly build to the MCU, without leaving the Debug session.

    MichaelH said:
    and sometimes I have a bunch of breakpoints in the code

    Breakpoints can be dis-/enabled with one mouse click, either way -before starting- or –during- a Debug session.

**Attention** This is a public forum