FET430UIF and EEM trace capability

Sergei,

I ran into the same problem. IAR 5.40.7 does NOT support EMM. Worse, they do not know when or if they will do so again! That is what I got from customer support a couple of weeks ago. So you either backtrack to something like 5.30.4 and the older DDL for the FET or try CodeComposerStudio (I do not have experience with CCS).

Andres

Andres,

I do not use IAR or CCS. I have used mspgcc for 8+ years and am very happy with the compiler. Installing CCR and IAR was a desperate move aimed to understand how the EEM trace feature works. At this time I believe it does not. TI has a bunch of appnotes referring to the trace working with older versions of tools and DLL. I suspect DLL got broken in v3. Can somebody from TI confirm that? And if it is broken, is there a plan/timeline to fix it? It is a shame to have that fantastic hardware feature crippled by software.

Sergei

Sergei,

I agree with you that the tools (at least IAR, which is the one I know) are not up to the MSP430. At least not if you want to get into more in-depth debugging. I also have the sense that the DLL for version 3 is not ready. I had to move to an older version of it because using the latest release was corrupting the clock registers after a break point! You cant' imagine how much time I wasted chasing that problem (see thread  RE: Basic Clock Module is in different state when using the debugger )

After reading about you usign mspgcc, I think I will give it a try.

Regards,

Andres

Andres,

Regarding mspgcc, be forewarned that it is a great compiler but not an IDE. If you are used to IAR tools, the learning curve may be a bit steep. You can setup an eclipse IDE to use mspgcc backend if you are so inclined. It all boils down to what you are comfortable with. GNU tools give you full control, you always know what is going on in your build system  and code is scalable and portable to other platforms. I routinely compile the same C modules for MSP430 and PC/Cygwin. Also notice that I said "great compiler", debugging with JTAG always had problems.

Still no response from TI support ppl? Hello? Are you out there? Plz, any info on EEM trace with v3 dll would be very helpful.

Regards,

Sergei

Sergei,

Thank you for your advice on mspgcc. I will probably not jump on it right away but I will keep it my radar. I will try to get comfortable with Eclipse first. Indeed, usign CodeComposerStudio v5 may help to get used to Eclipse. They offer a 90 day trial period. But then again, there may be some issues with it -and support may be less than ideal.

Regards,

Andres

I too use mspgcc (the older version 3.2.3) for many years now, and I don't want to switch. The IDE I built around it is UltraEdit Studio. No debugging at all (I never bothered to set a debugger up - I have to deal with realtime things, so a debugger is normally useless).

I know Eclipse form Java development and the eclipse based FlashBuilder. Nice, capable - and slow. Those 'thinking breaks' it sometimes takes drive me crazy. A powerful monolithic text editor might not offer all the gadgets, but it 'does the job' and does it quick. And I have full control over my build process, no problems with access rights and path names or other 'automatic failures'. Definitely a steeper learnign courve for the first 'hello world', but after that it rusn fine. And the compiler itself offers a good bunch of nice feature that aren't available on GCC or IAR - including the powerful inline assembler notation.

Jens-Michael,

Thank you for the information on mspgcc, UltraEdit and FlashBuilder. It is good to know how other people do things.

I do need a debugger. I particularly like to have trace capability. Unfortunately, that is hard to do with the current level of support for the MSP430. I am surprised that you can get away without using a debugger. More power to you!

Andres

Andres Aguirre1 said:

I do need a debugger.

Well, for the 3.2.3 MSPGCC, there is GDBProxy and you can use GDB (GNU debugger). However, the old MSPGCCs toolchain only supports the 1x/2x/4x family devices and not the newer ones with 20bit X/X2 core (those with >64k addressing range). So the 5x/6x devices as well as some of the 2x family (especially those with SBW only interface) are not supported. The compiler works with them, and I can flash these newer devices with the Elprotronic tool. But no debugger.

The current MSPGCC does support them, but unfortunately the toolchain, especially GDBProxy and GDB, does not. Some basic debugging features are available for virtually all MSPs through MSPDebug project.

Andres Aguirre1 said:

I am surprised that you can get away without using a debugger

Well, I use thing slike LEDs/digital I/Os for signalling (which I can synchronize with the input signals on the scope). And before I got the serial ports working on the 54xx, I produced a 16 bit debugging output by the duty cycle of a timer outpu tpin, measure with an external precision counter. Sufficient for giving me a 16bit value (as long as neither low, nor high byte are zero). After the serial was working, I was able to send debug/trace poutputs through background transfers (ringbuffer and interrupt-driven send). Requires inserting printf wher eI want to know variable states or memory contents, but doesn't slow down the program execution at all (as long as I don't try to send more and faster than the serial baudrate allows).

Well, I wrote my first assembly programs on a C64, with no chance of a debugger. So I see it as a convenient tool but not a mandatory one.

I only pull out JTAG debugger when I hit some inline assembly problem or if a device cannot support printf due to the memory limitation. For timing analysis, toggling an output pin does the job. As JMG said, JTAG debugger is too intrusive for a real-time system and I am yet to see it working reliably. It is hard enough to find my own bugs without chasing tool problems  ;-)

Said that, it would have been really nice if mspgcc provided a better support for JTAG for those rare occasions when I do need it. I normally like using command like tools but debugger is not one of these cases. And adding a GUI front end for gdb opens another can of worms. Insight has never worked right and setting up Eclipse so that I can use a debugger is too much.

Now, coming back to the original topic, since we have not heard from TI ppl. I will just assume that DLL v3 is broken and there are no plans to fix it.

Sergei

Sergei Sharonov said:

since we have not heard from TI ppl. I will just assume that DLL v3 is broken and there are no plans to fix it.

Well, it's no secret that DLL v3 has lots of issues, and I guess, the trace is one of the less important ones. They are dfinitely workign on fixes, but first the 'mainstream users' need their toolchain working flawlessly again. There are so many issues with FET up/downgrades etc, so that features that aren't even supported by the major compilers surely will be far down on the bug list.

So I don't say there are no plans to fix it, but there are likely many plans to fix other things first.

Jens-Michael Gross said:

Well, I wrote my first assembly programs on a C64, with no chance of a debugger. So I see it as a convenient tool but not a mandatory one.

Not mandatory tool but extremely useful. I can only imagine what it would be like to chop a tree with an handsaw instead of a chainsaw.

By the way, do you know of an in-circuit emulator (ICE) for the MSP430? I used one when I worked on a then Mitsubishi M16C (now Renesas). That tool really gave me control and solved several obscure problems.  Sometimes the choice of a microcontroler comes down to the tools available. In this respect, the MSP430 will come out ahead.

Andres

Andres Aguirre1 said:

 In this respect, the MSP430 will come out ahead.

I am sorry, I misprinted the previous sentence, it should read: "In this respect, the MSP430 will NOT come out ahead"

Andres

Andres Aguirre1 said:

I can only imagine what it would be like to chop a tree with an handsaw instead of a chainsaw.

Did it with both, and with an axe. Chainsaw was the fastest, but the axe was the most satisfying :)

Andres Aguirre1 said:

By the way, do you know of an in-circuit emulator (ICE) for the MSP430?

Well, the FET comes close. However, teh debugging software that uses teh FET doesn't.
Each MSP has an internal EEM unit that allows controlling the CPU and the ADDRESS/DATA bus. Teh debugger uses this for setting breakpoints, but you can do much more (in theory, as there isn't much documentation). The FET provides access to this EEM. And the debugger only uses a fraction of its possibilities. The protocol overhead between PC and JTAG adds to the gap between possible and implemented uses. Especially a trace buffer and conditional breakpoints are possible in hardware but not really used. Mainly because not all MSPs have the same EEM feature set.
However, the relatively low speed of JTAG is a limitation compared with a real ICE. But I don't know of a bond-out version of the MSP.