430G2 launchpad + CCS functionality help

vladn said:

Does the program run on the socketed device or in the emulator part ? Are they independent ?

The official name for 'the emulator part' is FET (Flash Emulation Tool). The keyword here is 'tool'. The FET is no emulator by itself. It is a tool to form an emulator together with an actual MSP. FET+MSP=Emulator.
So they are not independent regarding debugging. Even though the FET contains its own MSP.

The program runs in the actual target MSP, not inside the FET.

vladn said:

Does run->debug actually program the flash memory on the socketed device ?

Depends on the debugger configuration. But it usually makes no sense to start a debug session without having the program running in the target device. So teh default config is to indeed upload the program to the target device.

BTW: IAR provides a 'simulator'. It is independent of FET and MSP. A plain software simulation.

vladn said:

If the answer to #2 is "no" can I use the CCS+Launchpad to flash the socketed device when the project is finished and use it outside of the launchpad ?

You can, even though the answer is yes :) However, the upload is done (or not) when starting a debug session. Which is not really suitable for production.
YOu can isntead tell teh linekr to additionally generate a TI.TXT output file which does only contain the binary data and no debug information. This file can be used with various tools (e.g. the free Elprotronic Lite FET-Pro430) to directly program the MSP, without CCS running.

vladn said:

2.b If "yes" is it possible to avoid flashing the device every time I debug something ?

Yes. You can deactivate the upload. But don't forget to activate it again when you do changes on the firmware. Else you'll feel like Alice in Wonderland when debugging :)

vladn said:

I need some quickstart guide on the launchpad emulation / debugging / programming functionality and some explanation how the launchpad interacts with the CCS in different modes.

Well, the FET part of the LaunchPad (as well as the 'real' FET430UIF) knows the MSP, its memory map, clock system, flash controller, enhanced emulation module etc. Upon request from the debugger, it can set hardware breakpoints, inject data into memory, read CPU status and so on. Including storing a new program in flash. And report back to the debugger when a hardware breakpoint is hit, or other things happen.
The debugger simply issues a command like 'stop CPU', 'read memory', 'write to memory' through a virtual serial connection and the FET does the job through a JTAG connection to the MSP.

vladn said:

(I assume that the soldered M430F1612 can not be used for anything else except the emulator service functions).

Well, it could - be reprogramming it. After all, it's a normal 1612 :) But you'd need a FET430UIF for this (or a self-designed BSL frontend) The 1612 on the LaunchPad cannot be used to program a 1612 on a different LaunchPad due to incompatible programming signals (4-wire JTAG vs. 2-wire SBW)

vladn said:

Ok, but I don't think I can fit in a 4k free code size limit with my final project.

I just mentioned it for completeness of my answer. IAR free version is good for minor projects, but the full version is quite expensive.
Alternatively, you can use MSPGCC, which has no limitations and is free, but doesn't come with an IDE. Everything is driven by self-written makefiles here. And debugging is not as streamlined.
Since I don't use a debugger, I have no problems using MSPGCC. (or did I get used to not using a debugger because I use MSPGCC? A hen-and-egg question)

vladn said:

So basically I compile the "Release" configuration, hit the debug button and get a functional uP, no restrictions ?

The main difference between debug and release version is that the release version doesn't generate full debug information in the linker output file, and the debug version generates a global define '_DEBUG' or so, that can be used to conditionally compile debug code when the debug version is built. But on the bottom line, both, debug and release, are just 'config1' and 'config2' with some different presets. So the answer is a non-exclusive yes. :)

vladn said:

This is a hobby project for now, but I may need to program 10-100 devices. If it ever goes beyond that I'll get some kind of ISP accessory (and a commercial CCS license).

You can download the Lite Fet-Pro430 from Elprotronic (http://www.elprotronic.com/download.html). If you tell the linker to generate an additional TI.TXT output file, you can use this as input to the Elprotronic software which is designed to only program MSPs (no debugging), but quickly. I use it for MSPGCC too.
Of course, there are GANG-.programmers too (simultaneously programming multiple MSP targets) - for a price.

vladn said:

Is there a reason to deactivate the upload if the target behaviour does not change ?

For extended or repeated debug sessions. Not always the bug is found on first try. Or in one day. Or the debugger is used for observing code results on multiple runs. No need to waste time in uploading the firmware again and again then.

vladn said:

it looks like every time you change the code you waste a flash write cycle on the target uP

Indeed. One of at least 10k and typically 100k cycles. If you completely reprogram the MSP every minute, 24h/d, you'll have 1 to 10 weeks lifetime (I don't think you can do it much faster). In real life, I don't think that anyone has ever reached the life limit of the flash.

vladn said:

The "FET" name is a bit confusing though, it implies that the target flash memory is not used or written but rather replaced with some sort of external circuitry

Yes, that was the historical way of doing an Emulator. Replace the processor with a complex circuit that allows supervision of the internal actions. However, on MSP430, the supervisor circuit is built into the processor already (the EEM). And the FET is only required as the external (high-speed) frontend. (in theory, a direct PC port like a parallel port could do the job under PC software control - but would be awfully slow)
BTW, originally, there have been the MSP430C devices with mask-programmed ROM instead of Flash. In this case, I guess (and that's just a guess), the FET was really emulating the Flash memory too :)

vladn said:

Is there a TI document that describes the Launchpad FET part and how it works with the CCS ?

There are documents about MSP JTAG programming. That's the interface between FET and MSP. The two documents I have are named SLAU149a.pdf and SLAU320e.pdf. Probably a newer version is online now. use the TI main page search (not the forum search).