Cannot update CCSV4 Beta 5 to service release 4.0.0.14900

Very odd that those files are not present.  Did you do a custom install of CCS?  I am wondering if one of the custom install options causes these plug-ins to not get installed.  Attached are a couple of plugins that you may need to drop into \ccsv4\eclipse\plugins

Regards,

John

Placing those files in the \ccsv4\eclipse\plugins folder did not work, nor did extracting the jars there.

However, you appear to be correct in your guess that it is related to the custom installs.  I had done the "MSP430-only Core Tools" installation - this does not work. I uninstalled, deleted all leftover files, then installed choosing "Microcontroller Edition" and this worked (without needing to copy the plugin files).  To verify, I then uninstalled again, deleted leftovers, and installed with the "MSP430-only Core Tools" installation and again it did not work.  I verified this on both Windows Vista 64 and Windows XP.

I then did the "Microcontroller Edition" installation again but this time unselected the various emulators associated with the C2000 since I do not need them at this time and this also worked.  Something about the MSP430 core tools installation must be missing the plug-ins needed for the updates. 

I captured the two lists of components to be installed - the item I noticed that seemed possible is that the MSP430 install does not include DVT.

Now all I need is a Windows Vista 64 compatible driver for the MSP-FET430UIF - I was hoping this update would have it.  Windows finds a driver "MSP-FET430UIF - VCP" but says "Driver is not intended for this platform".  Any ETA on this?

Thanks

Thanks Edward.  That makes sense.  The update checker actually goes and scans all the "features" that are installed and does a dependency check on them when doing an update check.  If one of them fails it will prevent you from installing additional updates.  DVT is a package that we use on DSP & ARM for profiling and OS visualization... things that are currently not applicable to MSP so it doesn't get installed in the MSP-core config, however it looks like something else that does get installed is expecting elements of it to be present.  I will talk with our install team and see if this is known and correct and if not get something filed for it as this could be a big issue.

I will try to get some info on the ETB for 64b MSP UIF drivers.

Regards,

John

Edward,

We just checked and the update issue is resolved for the core config in the release candidate.  BTW we just posted the release candidate if you are interested.

http://tiexpressdsp.com/index.php/Category:Code_Composer_Studio_v4

Regards,

John

Thanks John.

I downloaded and installed the release candidate. MSP-430 core only, on both Windows XP and Windows Vista 64 and noted the following:

1) During the installation, the window that comes up with the list of components that will be installed does not list DVT but the next window that steps through the installation does show DVT being installed.  Not a big deal but thought I would mention it.  I cannot verify the updater since there are no service updates available yet but it looks positive that it did install DVT - assuming that was the source of the original problem.

2) The installation installed a license file that did not match the host ID of the computer I was on - when selecting the licensing options from the menu it just came up with an error window.  I had to manually delete the license file in order for the licensing options to come up.  It would have been nice if it could have still brought up the licensing options window rather than make the end user search that nightmare of a path for the offending file.  This happened on both of my machines, so I am assuming that this file was not supposed to be included in the installation in the first place, but I can see where this might happen to someone that has to replace their network card (hence changing the host ID making the license file invalid).  Ironically, when you already have a valid license the license options comes up just fine - even though you don't need it.

3) The MSP-FETU430UIF is still not working on Windows Vista 64 - same error as before - I assume this is due to no 64-bit driver available yet - any update on this?  I really don't like having to switch to my old slow computer to do my debugging so I'll probably keep asking this until you give in and toss me a 64-bit driver :)

-Edward

Two more issues, one simple, one difficult.  These issues are not new to the release candidate - the beta 5 release had these as well.

1)  The SVSCTL (SVS Control Register, MSP430x2xx Family User's Guide section 9.3, page 9-7) is missing from the header files and linker command files.  This also happens to be missing from the IAR header files.

2) On my Windows Vista 64-bit machine, the Project->Properties->C/C++ Build->Configuration Settings tab will not display (shows a large blank area where the configuration settings should be.  This works on my Windows XP machine.  I'm guessing you will need a bunch of information regarding my machine to be able to fix this one.  It is a Gateway FX6800-09 and I am running dual monitors (video card is NVIDIA GeForce GTX 285), display 1 = LG W2361VG, 1920x108 pixels, 32-bit color, display 2 = LG W1952TQ, 1440x900 32-bit color.

The only way I have gotten the configuration settings to show up on the Vista 64 machine is to run in 640 x 480 compatibility mode and even that is hit or miss on it working.  As far as I can tell, all of the other property screens appear to be working correctly.

If you need any other information on Item 2 let me know.

-Edward

1) During the installation, the window that comes up with the list of components that will be installed does not list DVT but the next window that steps through the installation does show DVT being installed.  Not a big deal but thought I would mention it.  I cannot verify the updater since there are no service updates available yet but it looks positive that it did install DVT - assuming that was the source of the original problem.

Yes we don't list DVT as a user configurable install option it gets installed based on what you select.  However now I think it gets installed all the time as many things are making use of it and this fixes the bug you saw.

2) The installation installed a license file that did not match the host ID of the computer I was on - when selecting the licensing options from the menu it just came up with an error window.  I had to manually delete the license file in order for the licensing options to come up.  It would have been nice if it could have still brought up the licensing options window rather than make the end user search that nightmare of a path for the offending file.  This happened on both of my machines, so I am assuming that this file was not supposed to be included in the installation in the first place, but I can see where this might happen to someone that has to replace their network card (hence changing the host ID making the license file invalid).  Ironically, when you already have a valid license the license options comes up just fine - even though you don't need it.

The way it is supposed to work for the core tools is that you won't ever see the license dialog as it will create a license for you automatically.  Something may be going wrong with that, we will test it out some more on our end.

3) The MSP-FETU430UIF is still not working on Windows Vista 64 - same error as before - I assume this is due to no 64-bit driver available yet - any update on this?  I really don't like having to switch to my old slow computer to do my debugging so I'll probably keep asking this until you give in and toss me a 64-bit driver :)

I will let you know as soon as I get an update on this.

4)  The SVSCTL (SVS Control Register, MSP430x2xx Family User's Guide section 9.3, page 9-7) is missing from the header files and linker command files.  This also happens to be missing from the IAR header files.

I will file an issue for this. 

5) On my Windows Vista 64-bit machine, the Project->Properties->C/C++ Build->Configuration Settings tab will not display (shows a large blank area where the configuration settings should be.  This works on my Windows XP machine.  I'm guessing you will need a bunch of information regarding my machine to be able to fix this one.  It is a Gateway FX6800-09 and I am running dual monitors (video card is NVIDIA GeForce GTX 285), display 1 = LG W2361VG, 1920x108 pixels, 32-bit color, display 2 = LG W1952TQ, 1440x900 32-bit color.

Does it happen with any other dialogs?  Does it happen on both monitors?  My main machine is Vista32 with dual display (1680x1050 +  1280x800), NVIDIA GeForce 8400M.

As far as I could tell it was only that one screen that did not work correctly.  One theory I had is that it might have to do with the list panel on that screen with the horizontal and vertical sliders as that seems unique to that screen. 

The file extensions screen has a vertical slider but that one seems to work; although there was a small difference on that screen between the XP machine and the Vista machine - on the XP machine the vertical slider looked active and on the vista machine it was greyed out like it was disabled.  I am not at those machines right now, but if I recall correctly the slider did not actually work on either the XP or the Vista machine.  I did not play around with that screen since it is not something I envisioned needing to ever change.

I don't think that it is related to the multiple tabs on the configuration screen since there are other multi-tabbed screens that are working - unless the build configuration tab panel is implemented differently that the others?

I have not fully tested all of the screen options with the release build, but with the beta 5 build I had tried both monitors in dual mode, each monitor in single mode, various screen resolutions and different compatibility mode settings.  The only thing I found that had intermittent success was to use the 640 x 480 compatibility mode.  In 640 x 480 mode I could open and close the properties and sometimes the screen came up and sometimes it did not.

Later today I can try disabling some of the video acceleration and other options to see if that makes any difference - do you have any suggestions on what to try?

-Edward

I tried a bunch of video settings and still the only one that has any success is the 640 x 480 compatibility mode.

One interesting note - in the 640 x 480 mode, if I open the properties screen, select the build settings, close the properties, re-open the properties (so it starts on the build settings), it will not work.  I can then select a different screen, such as Info, close properties, open properties, select build and it works.  This was 100% repeatable.

Also if I close on the builders screen, open properties and click on build, it will not work.  However, if I click on one of the other screens and then on Build it works.

Also of note is that even when the build screen shows up in 640x480 mode it does not show up correctly.  Instead of using the whole area it only uses the top left quarter of the area (1/2 the width and 1/2 the height).

Let me know if there is anything else I can try or information I can provide to help figure this one out.

-Edward

Edward,

For the SVSCTL issue.  Which header files is it missing from.  I filed a bug for this and the owner would like to track it down.  I looked in msp430x23x.h and I see it defined there.

I am trying to pull in some other people on the display issue.

Regards,

John

This may be my error.  On looking back through the family user guide I noticed this register is only on "selected" devices in the family.  I had thought it was on all of them.  We are using the MSP430F2272 and it looks like this part does not have the SVSCTL register so the header is correct as is.

-Edward

Good news - Adrian replied to me on another thread with a link to the new released beta 64-bit driver and that seems to be working as well as the 32-bit so far.

More news on the display issue:

On the display issue, I have found more screens not displaying correctly.  Now that I can debug on the 64-bit machine, I found that the CCS Debug settings are not coming up quite right all the time either.  The grouped settings, such as PRogram Verification Options, Realtime Options, Auto Run Options, Launch Options, Connection Options, OS Aware Debug Options, Automatically load module symbols, and the Download Options (under MSP430 Properties) are also not always coming up.  This is a little different though in that they were all empty at first but as I switched back and forth between screens they started working and once working did not dissappear again.  Not all of them started working at the same time, however, and the Program Verification Options and Automatically load module symbols did not fix themselves at all (those two are still empty).

The Main tab of the CCS Debug Settings is also intermittent on working / coming up partial / coming up blank.

New bug - trouble setting breakpoints - this is happening on both the Windows XP machine as well as the 64-bit machine.  The Windows XP machine works fine with the same source code and settings running version 3 but has lots of trouble with version 4.  I do not recall having this problem before the release candidate, or at least not this reliably.  This happens every time I try to debug with breakpoints.

With no breakpoints set, when I try to add a hardware breakpoint I get an error popup from the Breakpoint Manager that says "Insufficient resources.  You can free up one resource by disabling software breakpoint support".

I also get error messages like this:

MSP430: Breakpoint Manager: Could not read Enhanced Emulation Module register

MSP430: Trouble Halting Target CPU: Could not terminate EEM polling thread.

-Edward

I verified that the breakpoint problem is a new bug with the release candidate.  I went back and installed the full version of beta 5 (CCS_4.0.0.14000) and it worked fine.  I could set a hardware breakpoint, remove or disable the breakpoint, add a new hardware breakpoint, go back and forth between breakpoints, etc.  As long as I only had one hardware breakpoint enabled at a time it worked just fine.  I only got the error when I tried to have 2 hardware breakpoints enabled.  This is correct and expected behavior for the part I am using (MSP430F2272).

To compare apples and apples, I then uninstalled beta 5 and installed the full version of the release candidate (CCS_4.0.0.15000), just to make sure it was not a core-only problem again.

With the release candidate, I can set one hardware breakpoint, once and only once.  As long as I keep that breakpoint enabled it works.  As soon as I remove or disable that breakpoint I cannot add a new one nor re-enable the one I disabled.  It seems as if the debugger is not properly removing the breakpoint (either the MSP still thinks it has a breakpoint or the debugger's internal count of breakpoints is not being updated).

For now, I will have to go back to the 4.0.0.14000 version since I cannot effectively do any debugging with the release candidate until the breakpoint bug is fixed.  Let me know when a new release candidate is available and I'll be happy to continue testing it.

By the way, while I had the full 4.0.0.14000 and the full 4.0.0.15000 versions loaded I verified that all of the display problems I have with the core-only release candidate are the same in both full  versions so the display issue is not new in the release candidate nor is it a full versus partial installation issue.

-Edward

Edward,

Thanks for the detailed analysis, we will look at this right away.

John

Edward,

I was unable to reproduce the breakpoint problem with the hardware I have immediately available (the closest device I have is a MSP430F2274). Would you be able to confirm that this test case does not work for you:

• open the target configurations view
• if you don't already have a configuration for the f2272, create one by clicking the new button and filling the connection and device information
• save the configuration
• right click on the f2272 configuration and select "launch selected configuration"
• after the debug session has launched, click on the "connect target" button in the toolbar
• right click on any address in the disassembly view, and select "new breakpoint -> hardware breakpoint"
• repeat for a second address (error expected unless you have disabled software breakpoints)
• disable the first breakpoint, and add a second one at a different address
• I understand this is where you would receive an error message about insufficient resources, correct?

 Thanks for your help with this.

Andy

I will run this test when I am back at my home office later today, but in the meantime I have some questions:

1) Your 7th bullet item -- "repeat for a second address (error expected unless you have disabled software breakpoints)" -- is this correct or should it be "(error expected unless you have not disabled software breakpoints)" ?

2) Could the port initialization for port 1 bits 4 through 7 (the pins shared with the JTAG) in my software be causing a problem in the release that was not a problem in the previous revision?  When I configure port 1, I have these 4 pins set as inputs with the internal pull-ups enabled and I set P1SEL = 0.

3) Are you loading a target image and having it run to main?  I have not tried unchecking the "run to main" box.  I have tried disabling software breakpoints as well as the CIO thing.

I do not recall whether I tried setting various breakpoints prior to running the target through my initialization code.  I will test this along with the test you requested.

All of the breakpoint tests that I tried were done in the C source window, not in the disassembly view as your test suggests, so testing this may shed more light on the issue.

I can also try only using software breakpoints.  I generally live with just the hardware breakpoint because I want the target to run at full speed between breakpoints.  This test might help prove out whether it is a port initialization problem.

To answer your question, if I recall correctly, I receive the "insufficient resources" error just by disabling the first breakpoint and re-enabling it, but yes I would also get it in the manner you described (other than what I mentioned above about using the source window rather than the disassembly window).

-Edward

Hi Edward,

Thanks for your reply.

1) Your 7th bullet item -- "repeat for a second address (error expected unless you have disabled software breakpoints)" -- is this correct or should it be "(error expected unless you have not disabled software breakpoints)" ?

If you have the "use software breakpoints" option enabled, the debugger will use one of the two available h/w breakpoint resources under-the-covers to implement this. The option is is enabled by default for this device, so I was suspecting the one of the two resources would already be used. The second one would be used by the h/w breakpoint inserted earlier in the test case. In bullet 7, no additional h/w breakpoints would be available and you get an error.

2) Could the port initialization for port 1 bits 4 through 7 (the pins shared with the JTAG) in my software be causing a problem in the release that was not a problem in the previous revision?  When I configure port 1, I have these 4 pins set as inputs with the internal pull-ups enabled and I set P1SEL = 0.

I'm not sure. I'll need to defer to others on this point.

3) Are you loading a target image and having it run to main?  I have not tried unchecking the "run to main" box.  I have tried disabling software breakpoints as well as the CIO thing.

I was trying to eliminate as much as possible from the test case. One of the things I took out was loading any target program at all. The target would just be running whatever was already flashed on there when the connect occurs. When you click the connect button, the debugger halts the target program where ever it may be and connects to the device. In this scenario, the “run to main" option shouldn't have any effect as that only gets used if you load a program.

I do not recall whether I tried setting various breakpoints prior to running the target through my initialization code.  I will test this along with the test you requested.

Thanks. If this works then perhaps your point (2) is important to isolating this problem.

All of the breakpoint tests that I tried were done in the C source window, not in the disassembly view as your test suggests, so testing this may shed more light on the issue.

I get the same (working) behaviour when I load a program and set breakpoints from the source window.

I have not fully run through your test yet (have limitted time right now, will test more later), but I did rule out some things.

I modified my code to not do any initialization of port 1 - still does not work so this is not it.

I coded just a very small loop and kept interrupts disabled - still does not work but I get different results - instead of the resources popup I get red error messages in the console window that it cannot access the EEM registers.

MSP430: Breakpoint Manager: Could not read Enhanced Emulation Module register

MSP430: Trouble Halting Target CPU: Could not terminate EEM polling thread.

Before I hit run, I can set 2 hardware breakpoints, disable, re-enable, as much as I want.  The problems only start after I try to run the target.  Once it hits the breakpoint, I can't do anything more.

I'll give you more feedback when I get back again later.

-Edward

It took me quite awhile, but I believe I have the breakpoint issue narrowed down very specifically.  I believe the reason you could not duplicate the problem is a difference between your target hardware and mine.

For my hardware, I have P4.7 set as an output and I enabled the resister pullup on this pin.  As soon as I either set P4REN = 0x80 or P4OUT = 0x80 I can no longer modify breakpoints or even run the target.

It is possible the bug is something obscure about P4.7 or it is more the effect of setting that bit on my hardware.  This is a reset pin to another device on my target.  This device communicates with the MSP430 via UCA0.  The device connects to five pins of the MSP430 - P4.7 is the device reset pin, P3.4 and P3.5 for TxD and RxD, P3.6 and P3.7 are used for hardware handshaking to the device.  It is likely that one or more of these pins sees some state changes when P4.7 is taken high.

I have tried with both CIO enabled and disabled - no difference, does not work either way.  I tried forcing some signal changes on the RxD pin without setting P4.7 and could not cause it to mess up.  I don't know if this rules out the CIO possibility or not.

As strange as it sounds, my best theory at the moment is the problem is related to P4.7 being high.

I built a test code snippet that I used to verify this that has only a main() that sets up port 4 and then does a little variable manipulation in a for(;;) loop to give me something to set a breakpoint on.

On a side note - why do I have to manually define __MSP430F2272__ in order to #include "msp430.h"? The project is set up for this device, why is it not automatically defined?  Did I miss something when I configured the project?

-Edward

It must be my lucky night - just stumbled on a huge clue to the display issue!!!

I happened to notice that there was a horizontal scrollbar near the bottom left of the properties window - because that pane was not wide enough to display the list of property topics (Info, Builders, C/C++ Build, etc - specifically the C/C++ Documentation name did not quite fit).  As soon as I went to resize that pane - walla! the build settings were there!  I do not have to fix the size, just move it any amount, even narrower, and let go of the mouse.

Once the pane is wide enough, if I leave the build settings selected when I close the pane, I can go in and out of the properties screen and the screens are there.  However, if I leave the pane not wide enough, or I select something else, like Info, before I close it, I need to tweak the size when I re-open the properties in order to see my build settings.  I also have to do it every time I restart the program since it does not remember my resizing across runs.

Note that resizing the properties window itself does not fix the display - I need to specifically adjust the list window by clicking and dragging the divider between the list on the left and the stuff on the right.  I tried resizing the whole window on all four sides and none of them did it - just the list width.

Note also that just having the list pane wide enough is not enough to get me to avoid needing to resize it - I only get away not resizing the left list by having it wide enough and having closed it on the C/C++ Build selection.

I did notice that on some screens I had to go back and forth a few times to get them to fill in - this is similar to what I posted the other day about the items in group boxes not always showing up.

I tried to duplicate this on my Windows XP machine by opening the properties tab and shrinking the pane, closing and re-opening the properties, but on that machine it always works - I could not get the Windows XP machine to mess up at all.

So, I have a big clue for you, and a workaround for me that looks like might be something I can live with for now.

-Edward

Edward,

Thanks I will pass this on to the guy looking into it.  Great that you have a way to workaround it.

Regards,

John

Hi Edward, 

I just wanted to confirm the issue with build options. After a restart when you select project->Properties then right side of the dialog is blank until you move the divider that makes left side. Assuming my statement is correct, then I have tried reproducing this issue on 64bit vista, without luck. The properties dialog comes up with most categories visible, there is on that is cut off, but right hand side is always populated. If I make that left pane smaller, close the dialog and re-open then I still do not see the issue. Could do a screen capture of when you have the problem? Also, could you capture configuration information to a log file and send it? (Help->About Code Composer Studio : then click on "Configuration Details", there should be an option copy to clipboard and create a text file with information). 

Martin

Some of the properties screens do work - C/C++ Build always has the issue and I believe the CCS Debug Settings always does but I do not recall for certain.  Most/All of the other screens (such as Info and Builders) always work.

1) Start (or restart) CCS

2) Open Project->Properties

3) Select C/C++ Build on the left pane, right pane will have the couple things on the top but where the tabbed panel is for the Configuration Settings that area will be blank

4) Resize the left pane by dragging the divider with the mouse - as soon as you release the mouse button the Configuration Settings will show up correctly.  It will stay correct as long as you keep the properties screen open.  If you close the properties screen and re-open it, the results are dependent on what you had open and what size you left the left pane when you closed the properties screen.  If you either had the left pane wide enough to fit all of the text or had anything other than the C/C++ Build selected, you have to resize the left pane again to get it to show up.

If you can create a function that duplicates whatever normally happens on a resize of the left pane and call that function every time the properties window is opened that might fix the problem.

From the difficulty you have had in duplicating the issue, I suspect that the issue has to do with something very specific about the combination of hardware, operating system and drivers for my system configuration.  If this is the case, it might be best to just try my crude suggestion above and let me try it on my system.  I know this is not the most desired method of troubleshooting/debugging, but it might be our best option.

The system I have the issue on is my home office system.  I can get you the screen capture and log file you requested later this evening.  Where should I send it?

-Edward

Hi Edward,

For the breakpoint problem, I was still unable to reproduce it with the F2274 development board and your test program (re-pasted below). There does seem to be a target specific element to this problem. I'm asking around for some advice on next steps.

Regarding your question about defining __MSP430F2272__, you didn't miss anything in the configuration and I agree it would make sense to define this automatically. I've passed this along to the responsilbe team.

Andy

#define __MSP430F2272__
#include  "msp430.h"

The breakpoints worked properly with the 4.0.0.14900 and in 4.0.0.14000, just not in the 4.0.0.15000 so that should narrow it down to something that changed between the 14900 update and the 15000 release candidate.  Hopefully there were not many changes between those two builds.

I cannot run the 14900 any more (can't get that update since the 15000 surpasses it), but have been running the 14000 successfully all week with no breakpoint problems.

Note that there was also an update to the MSP430 FET tool between the 14000 and 15000 versions - or at least I have to do the firmware upgrade every time I move between the two versions.

-Edward

Probably best to attach it to the post(click on options tab when replying). Let me know if you have concerns with this.

martin

I included the log file and four screenshots - one of the C/C++ Build screen where it comes up blank, one of the CCS Debug Settings -> Target where the group boxes come up empty, and two showing some of the group boxes working and two of them still not working.

I have not come up with what exactly fixes the empty group boxes.  It seems that if go to CCS Debug Settings -> Target, then select anything on the left list other than CCS Debug Settings, then go back to CCS Debug Settings -> Target tab some of  the boxes will be working but some I have not been able to get to work at all.

I have not found a way to get the program verification options or the automatically load module symbols group boxes to work.

-Edward

Hi Edward,

Just a short update - the person I need to look into the breakpoint issue is out of the office until tomorrow, so I'm on hold unitl then.

Andy

Edward,

Could you also attach the .log file, located in your <workspace>/.metadata/ directory?  It might help us with the display issue you're seeing...

- Baltasar

Here is the .log you requested - I had to put it into a zip in order to attach it.

-Edward

Is there any update on either the breakpoint or display issue?

-Edward

Hi Edward, 

We are trying to setup a machine where we can reproduce the problem. The refresh happens in a relatively generic piece of code that would impact majority of other views, thus we are hesitant to just put in a hack without knowing whether it fixes the problem. Having a machine which duplicates the issue would allow us verify that the hack fixes the problem and potentially come up with a more optimized solution.

martin

Edward,

I haven’t received a definitive answer on the breakpoint issue yet. However, we believe the problem you are seeing is due to some changes that were made in a module called “MSP430.dll”. Therefore, a temporary workaround that would let you use the latest RC build would be to proceed as follows:

• Locate the two files called “MSP430.DLL” and “HIL.DLL” located in <install_dir>\ccsv4\DebugServer\drivers in your non-working Release Candidate install. Rename these two files to something else (i.e. MSP430.DLL.orig).
• Locate the same two files in the working release (same location) and copy them over to your RC build.
• Start a debug session from the RC build. You will be asked to upgrade the firmware. Allow that to proceed. (FYI, the firmware version is tied to the version of MSP430.dll. Each time that changes, the firmware needs to be reflashed.)
• Do a sanity test to ensure the breakpoint issue is not present.

Please let us know how that goes.

BR,

Andy