CCS/MSP430G2452: Nothing happens when building "blink" sample project in CCS.

A little update. It does not work if it is a different / mapped network drive.

Creating a folder link (mapping folder on network drive to local folder on C: drive) does not work either.

?

Which version of CCS are you using? 

Gennadiy Kiryukhin said:

've created a sample project "blink". When clicking Build button, nothing happens.  Debug folder is empty.

And nothing gets printed to the CCS build console either?

What is the directory on your mapped/network drive where you are creating the project - is it simply a mapped drive like D:\project_dir or something else?

 Version: 9.0.1.00004 

Uncheck use default location and under Location I select:

L:\products\myproductname\firmware\micro\

I select blink from Basic examples and it creates a project with blink.c and lnk_msp430g2452.cmd.

When I click on Build, nothing happens. The button is not grayed out. I tried Clean command and same thing the console is blank.

I checked CDT Build Console and CDT Global Build Console (a little monitor icon in the console tool bar) and both are blank.

However, if I create a project in the default location, it starts compiling.

FYI, all other tools we use including those for Windows software development, Altium for PCB design, other GNU ARM compilers (multiple versions) running in NetBeans + Cygwin, all work fine and have no problems with accessing files from the mapped network drive.

Gennadiy Kiryukhin said:

Uncheck use default location and under Location I select:

L:\products\myproductname\firmware\micro\

I would expect this to work. I tried with a similar mapped drive folder on my machine and it built fine.
Do you have write permissions to that directory?

What did you select for the workspace when starting up CCS - was that a local directory or also on the mapped drive? 

CCS has write access to the folder as it is able to create blink.c file along with .cmd. It also is able to greate debug and release folders too. However, there is nothing in debug or release folders.

For the workspace, I selected the default location which in somewhere in the user directory on local disk.

Any way to see any error messages of logs?

Thank you for providing an update about the cause of the problem. This is unfortunately one of the known pitfalls of migrating/working across different OS/file systems. As far as I know, Eclipse (that CCS is based on) has no plans to change the behavior for case-sensitive files - here is one bug report that I found on this topic (https://bugs.eclipse.org/bugs/show_bug.cgi?id=39488)

The #include situation that you mention is indeed another area where project builds could be impacted,hence the choice of file and path names should be one of the considerations when initially creating projects that are intended to be ported across OS. Sorry about the inconvenience.

The Eclipse bug you referenced is the opposite of this problem. According to the discussion under the link, Eclipse on Windows does not care about case and it matches Windows behavior. This means that Eclipse would see "debug" and "Debug" as the same folder, which is now what I'm observing. I think CCS problem is that the underling tools the CCS has added to Eclipse are case-sensitive. I have had similar problem with some of GCC compiler on Windows that complained about not finding files due to case difference.

Normally the 'Debug" folder is created when the new project is created and the Debug (default) configuration is set as active configuration. In your system, did the "debug" folder (with all lower case) already exist in the project folder or was it created that way when the new project was created? 

Debug folder was created when the project was created. Except that it was created in lower-case (network drive is Samba under Linux). I had to manually switch it the first letter to upper case to make it work. When I would switch to release mode, Release folder would be created but again in all lower case. I think this is where the system would stumble.

Yes, this requires a change in Samba configuration. I've already talked to our IT guy. He was reluctant to change it as it would affect everybody else in the company and could potentially break something else. As far as Windows is concern, Debug and debug is the same folder (you cannot manually create them at the same location) and programs under Windows should be happy with either one of them. Changing case of the file/folder should not break it.

To reproduce the problem, close the project (even if it is on local drive), change "D" to "d" and reopen it. It will stop working. I know that this could be considered as editing files behind the system but on Windows this should not break it. Making the software under Windows case dependent introduced an environment where there is a possibility of having two file/folder names created that differ in case. On Windows it can result in wrong file access or even lost files if handled by other software. The link to the Eclipse bug report you posted earlier would be a perfect example where case sensitivity would break things in Windows. (Quoting the post from that link: "...opening the second one, shows the contents of the first one. And deleting one may result in both being deleted on the file system." )

I have marked your post as "correct answer" because it illustrates how Samba needs to be configured to be compatible with current CSS.

Gennadiy Kiryukhin said:

To reproduce the problem, close the project (even if it is on local drive), change "D" to "d" and reopen it.

Yes the issue can be reproduced in this way. I also discussed this with our CCS build expert and he explained that when the project fails to build in the above situation, an unhandled exception gets logged:

This exception is thrown at the Eclipse level, so unfortunately there really isn't much we can do about it.  In addition to being built on top of Eclipse (which is platform independent), we also use many third-party utilities like Cygwin, Gmake, Node, etc., hence have to live with the constraints of all software that we integrate. 

Our recommendation to address this would be to change the Samba configuration, although I understand that is not the ideal solution for your environment. Sorry about the inconvenience caused due to this.