PSoC Creator & Designer Software

[Anonymous]

Opening a project that previously compiled in 2.2 in the new 3.0 release.

   

Clean and build project yeilds a bunch of errors, namely typedefs for uint8 etc. not found in cytypes.h.

   

device.h header file has an include for <project.h> where all of the other includes are called, including cytypes.

   

Right clicking on the #include <project.h> and selecting "Go To Implementation" gives the following cosole message:

   

"Unable to find implementation for . It may be in a library for which no source is available."

   

Thus it would appear that the new PSoC Creator 3.0 is not finding the include files as necessary.

[Anonymous]

        Hi SWohler   
I didn't have such a trouble ever.   
cytypes.h is reffered in this order device.h - project.h - cytypes.h   
And cytypes.h is there   
[ .../PSoC Creator/3.0/PSoC Creator/psoc/content/CyCompornentLibrary/CyCompornentLibrary.cylib/cy_bootv4.0/PSoC5/API ]   
Is your ToolChain set properly? [ ARM GCC 4.7.3 ]   
If you can't find any other cause, so you would be better to   
Re-install the Creator 3.0   

[Anonymous]

 Nothing has changed aside from updating the Creator software. The project is the same, and the toolchain is already configured (Keil 9.5.1). This is for a PSoC3, and the project heirarchy is set up exactly as you describe.

[Anonymous]

        Very strange,   
I have done on PSoC3 too, it's can build with no problem.   
Toolchain is DP8051-Keil-9.5.1, cytype.h is referred well   
What is your OS?, I 'm VISTA-32   
When you upload your prject bundle, I will check it out.   
It's OK most simple design but has a problem on your PC.   

[Anonymous]

My installation is Win-7 x64. I cannot bundle the project for you because it is confidential.

   

All of the includes are present AS GENERATED BY PSOC CREATOR, in the <project>/Generated Source/PSoC3/ folder.

   

The point is that the same project worked just fine in 2.2. Migrating to 3.0 caused the problem.

[Anonymous]

        Every engineer has confidential part, that's OK but I said   
"most simple design but has a problem on your PC"   
I meant, Do simplify your design, for example: There is only one pin design.   
So far, I have lost interest for this issue at all.   
Rise your case on "MyCase"   

[JoMe_264151]

        As a workaround #include        in the file(s) where the errors occure.    
    
Bob   

[JoMe_264151]

        Forum software swallowed the cytypes.   
   
Bob   

[RobynW_26]

We're not sure if your having an issue with the editor or compiling files.  Is the uint8 errors the first you see?  Can you open ctypes.h? 

   

Bob is right trying a #include where the error occures may help track down the issue. 

   

As for not being able to go to the include files... we weren't able to offer that functionality in 3.0.  We should be able to add it in 3.1.

[nicholausf_91]

I'm an engineer on the Creator team. Would you be willing / able to send your design directly to us (e.g., via email)? If not, would you be able to send a "minimal" design that still illustrates your problem? For example, you might be able to remove most (if not all) of the contents of your schematic, and most of your firmware and still reproduce the problem.

[EvPa_264126]

        I see a similar problem, but not in the file main.c However Project ---> Build without errors.   

[Anonymous]

 ↑ Very interesting

[Anonymous]

 I want to know how it does working like pavloven's images.

   

So I was make a simplest design and test it.

   

No error doesn't happen but

   

A slight clue I find.

   

main.c and test1,c has a same composition.

   

both refer uint8 form ctypes.h

       

On main.c, click uint8 and push F12(Go To Definision)

   

is made proper result, it can shows "ctypes.h"

   

Other hand on test1.c, It can't success.   

       

In these process, I find a different strangeness.

   

Look at the dummy1

   

It is made for global variables.

   

Look at Code Explorer, there are 4 dummy1 ?? 

   

something error might be occure?

   

I am confusing.

   

     Magic Window comming back!         

[Anonymous]

 This is a bundle 

[Anonymous]

 PSoC3 has a different behavior 

[nicholausf_91]

I've taken a brief look at 2to3_0.png and include_test.cywrk.Archive01.zip. Here's what I've found so far:

   

    
1. The reason why you see 4 versions of "dummy1" in the Code Explorer in main.c is because you created for variables with the same name (lines 18, 19, and two on line 20). The compiler will likely generate an error when you try to build (we support several compilers for PSoC5 and their error / warning reporting are all a little different).
    
2. You don't see any errors from the duplicate "dummy1" variables because traditional compilers are not designed to be integrated with text editors. We use a special C compiler that is specifically designed to support this type of integration. It also turns out that this special compiler is actually much more strict in its enforcement of the C specification than the command line tools used to actually build your project when you hit build. Rather than the editor produce an over abundance of errors and warnings, some that your compiler doesn't even enforce, we opted turn down the error and warning levels. The text editor will catch some (but not all) potential issues in your C code.
    
3. I still haven't been able to reproduce the issue in 2to3_0.png.
   

[EvPa_264126]

        A simple project with the problem. I wonder if it's on another PC?   

[Anonymous]

 Hi

   

It is deserved in happen the error.

   

Need include cytypes.h

   

Correct it and bundled. 

   

[Anonymous]

 BUNDLED 

[EvPa_264126]

        WIN64 - no problem   

[Anonymous]

 Your first bundle has no "project.h"

   

I was telling you.

   

Thank you. 

[EvPa_264126]

        Thanks, that helps. Another file: http://mylab.wmsite.ru/ftpgetfile.php?id=102 other problems: the picture below.   

[Anonymous]

 Yeah, I am looking my project and find it,

   

This is a same problem, The 3rd problem.

   

This is the initial failure of Creator3.0 pre-processor.

   

Strange thing is the project was builded in successful.

   

We are waiting Fix it, patiently.

   

[Anonymous]

 This is a component.h file also.  

[nicholausf_91]

 The API files in components are template files -- they are NOT legal C code. The are processed by PSoC Creator during the "API Generation" phase of the PSoC Creator build and turned in to legal C code. For example, `$PARAMETER` substitution happens, `=expresssion` substitution happens, and `#start` ... `#end` merge regions are processed. This is why you see the indicators in the sidebar of the .h file inside the component, but the project builds ok.

[Anonymous]

 Hi, 

   

I had the same problem as SWohler. Started a project in Creator 2.2 and migrated to 3.0, and now types are not reconized in the header files. It needs the "project.h" file.

   

To make a long story short and fix the problem, include the "device.h" file in your header files, not the "project.h" file. 

   

When you create a new project in Creator 2.2, it automatically creates a header file "device.h". which contains 

   

#ifndef DEVICE_H

   

#define DEVICE_H

   

#include <project.h>

   

#endif

       

When you create a new project with Creator 3.0, it does not automatically create the "device.h" file.  I do not know if this is a bug, or if this was intended.

   

This worked for me. 

   

Thanks, 

   

Robert

[Anonymous]

Nitro, the project already had a device.h include in main. device.h then has an include to project.h. The type definitions are only part of a bigger problem, that the Creator software is not able to find the include files that are already in the heirarchy / project directories. 

   

NSF-Cypress, I would be willing to send Cypress the entire project, and I had worked with several reps recently for a USB driver issue on the same project. This is through another company which has an NDA in place with Cypress. If you provide contact info I'll be glad to reply to you directly.

   

PSoC73, I'm sorry but I'm having trouble understanding you.

[Anonymous]

 Hello everyone, my students and I have found the same issue when trying to do the design in PSoC Creator 3.0. Though #include <device.h> appears in the c code, it does not appear in the list of files on the left side. This is what is causing other errors such as uint8 undefined etc. 

   

Does it have something to do with the path setting? Please help. 

   

Thanks

   

Moorthy

[JoMe_264151]

The file "Device.h" does not exist before the first successful build of the project. Since there are some more warnings in the PSoC3-environment get errornously flagged I would suggest you to run a complete build and analyze the warnings (and errors) from the compile-step.

       

Bob

[JiGi_284761]

I have the same sort of problem. Maybe....

   

Take a look at the photo. You can see that the h file is open yet the compiler cant find it.

   

Any Ideas. Is there some other way to reference it?

   

Thanks

[JoMe_264151]

@SCAS

   

You are modifying a generated file which you better better avoid. To write a handler for your isr_1 call in main() in the initialization part

   

isr_StartEx(Handler);

   

and have your handler declared and defined with

   

CY_ISR_PROTO(Handler);

   

CY_ISR(Handler)

   

{

   

    // here goes the handler code

   

}

   

as described in the "System Reference Guide" (to be found under Creator's "Help").

   

I presume that the file does not reside where Creator expects it to be, within the project folder. I would suggest you to remove the .h-file from the project (NOT delete) and then add the existing file to the project again.

       

Bob

[JiGi_284761]

Hi Bob.

   

I use that method also. However this method worked fine before.

   

I had just updated Creator and I had lots of problems like no access to C-functions. But I reinstalled Creator and all seem to work now.

   

Thanks

   

Jim