This question is further to my question a Why does EZI2C need a 60MHz clock?  But the mystery has deepened, and new evidence points to something strange happening in PSoC Creator.

Background:

I'm using the EZI2C device to emulate an I2C EEPROM. It is being read by an external device. I wired it up as you'd expect, using the special I2C0:SCL and I2C0:SDA pins. Data rate 300kbps, 1 address, Primary slave address 0x50, Sub address size 8, Pin connections Any. The PSoC's Master clock is set to 40MHz. The project is empty except for the EZI2C component and its pins. The main() function does nothing (just an empty loop) after setting up the EZI2C component.

At this point, everything is working correctly. The external device can read values as if there was a real EEPROM there.

Strange bit:

Next, without changing any code, or any other setting within the project, I delete the file SF_01.cywrk.Sandy Lunch which appears in my project directory. PSoC Creator almost instantly re-creates it, but it's not identical to the original. Then I press Shift-F6 to build the project. The output says:

--------------- Build Started: 04/18/2013 17:50:43 Project: RNX-PCB-ST-GIO_00, Configuration: DP8051 Keil 9.03 Debug ---------------

The code generation step is up to date.

The compile step is up to date, no work needs to be done.

The link step is up to date, no work needs to be done.

--------------- Build Succeeded: 04/18/2013 17:50:44 ---------------

Looks like that workspace file isn't required by the build process right?  --  Wrong!

Next I do a clean and build, and re-program the PSoC with the new code. Now it doesn't work properly. The external device only sees nonsense values coming back from the PSoC. Then, if I increase the master clock to 60MHz and re-build and re-program, the EZI2C seems to work again.

What's going on here? Why is there a generated file which affects the build process like this? If it affects the build process, then why doesn't the build process know that? What on earth is contained in this file that is affecting my project in this way? 

Good detective work!

Although I don't know the answer, I hope someone can.

I had a look at the <Project Name>.cywrk.<User Name> file that you mentioned, and it's an XML file .

Most of it is devoted to a list of all the files in the project, and if it's an object file, all the dependancies (e.g. the .c file it was built from and the .h files that were included in that .c file).

It also has name/value pairs, remembers what things you were watching in the debugger/breakpoints, the last schematic tab you had open and a few other things that I can't quite work out.

The strangest part is it seems to include assembly functions/compiler directives, like "NOIV", "MODDP2", and "OMF2" (this was compiling for PSoC 3, using the Keil C51 compiler). There are a bunch of them listed for what looks to be every .c file in the project. Maybe this could be related to your issue?

The IDE is not at all ment to be a stable backup system tolerating deletion of essential parts. When such a file is re-generated because it was missing some of the newly contained informations are right out of the blue. One essential point might be the creation date which now is younger than the rest of the pack, showing what has to be rebuilt: - nothing. I'm afraid that tracing what all happens when parts of a file system (aren't there I-Nodes?? Good target for experiments...) are corrupted or deleted. I would suggest to (as I had to do twice so far) open up a new project and cut&paste all the files and schematics form the old one into the new. This will give you a new point to start from, run a "Create workspace Bundle" next.

Bob

Hi Bob,

Indeed, there's no reason the IDE should tolerate random deletion of files. Here's some more information about what's happening.

In a typical software project (maybe a PIC project, or a Visual studio, or simply a non-IDE based one) there are three types of file.

Firstly, there are the files which make up the specification of the project. These are the source files (.c and .h), plus the make files, and in some cases a project file which is really taking the place of a make file, in that it tells the IDE which compiler settings to use. All of these files are stored in the version control system. I know that anyone can check out these files, and build an identical copy of the binaries. These are the files which appear in the source tree

Secondly there are generated files (.o, .d, .lst, .hex, .rpt). These are generated at build time. They do not go into the version control system, and I could delete them at any time, and the build process can easily re-create them.

Lastly there may be a few files which record the user settings in the IDE. How were all the windows set up, what's the list of recently used files, etc. This would not go into the version control either. The reason for this is that moving the windows around in your IDE would cause this file to be changed, and would make the revision number increase every time you just moved a window.

The problem with PSoC Creator is that it confuses these important distinctions. For some reason, there's a file which doesn't appear in the source tree (and I don't seem to be able to affect its contents through the IDE). It's automatically generated, and doesn't seem to contain any information relating to the build process. The build process doesn't even recognise that changes in this file need to be propagated through to the binaries. And yet, somehow, there's something in here which is the difference between my project working and not working.

This is incredibly frustrating, because now I don't know what to do. When I started a new project recently, I discovered that the PSoC didn't do what I expect it to do. Not even when I copied all of the relevant schematic and code from another project which is working.

If I want to store my project in a version control system, like SVN, I need to know what files should be added to the SVN (Topdesign, main.c, etc.), and what files are simply generated (everything in Generated_Source, for example). For some files it's obvious, but for some files it really isn't.

For example, the cywrk files seem to get generated automatically, as do cycdx, cyfit, etc. These are generated as part of the build process and are not part of the specification of my design. 

 Oops, ignore the last two paragraphs. They didn't get deleted for some reason.