cancel
Showing results for 
Search instead for 
Did you mean: 

PSoC Creator & Designer Software

Anonymous
Not applicable

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.

0 Likes
Reply
31 Replies
Anonymous
Not applicable
        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   
0 Likes
Reply
Anonymous
Not applicable

 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.

0 Likes
Reply
Anonymous
Not applicable
        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.   
0 Likes
Reply
Anonymous
Not applicable

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.

0 Likes
Reply
Anonymous
Not applicable
        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"   
0 Likes
Reply
Esteemed Contributor II
        As a workaround #include        in the file(s) where the errors occure.    
    
Bob   
0 Likes
Reply
Esteemed Contributor II
        Forum software swallowed the cytypes.   
   
Bob   
0 Likes
Reply
Employee

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.

0 Likes
Reply
Employee

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.

0 Likes
Reply
Valued Contributor II
        I see a similar problem, but not in the file main.c However Project ---> Build without errors.   
0 Likes
Reply
Anonymous
Not applicable

 ↑ Very interesting

0 Likes
Reply
Anonymous
Not applicable

 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!         
0 Likes
Reply
Anonymous
Not applicable

 This is a bundle 

0 Likes
Reply
Anonymous
Not applicable

 PSoC3 has a different behavior 

0 Likes
Reply
Employee

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.     
  3. 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.
  4.     
  5. I still haven't been able to reproduce the issue in 2to3_0.png.
  6.    
0 Likes
Reply
Valued Contributor II
        A simple project with the problem. I wonder if it's on another PC?   
0 Likes
Reply
Anonymous
Not applicable

 Hi

   

It is deserved in happen the error.

   

Need include cytypes.h

   

Correct it and bundled. 

   
        
0 Likes
Reply
Anonymous
Not applicable

 BUNDLED 

0 Likes
Reply
Valued Contributor II
        WIN64 - no problem   
0 Likes
Reply
Anonymous
Not applicable

 Your first bundle has no "project.h"

   

I was telling you.

   

Thank you. 

0 Likes
Reply
Valued Contributor II
        Thanks, that helps. Another file: http://mylab.wmsite.ru/ftpgetfile.php?id=102 other problems: the picture below.   
0 Likes
Reply
Anonymous
Not applicable

 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.

   
        
0 Likes
Reply
Anonymous
Not applicable

 This is a component.h file also.  

0 Likes
Reply
Employee

 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.

0 Likes
Reply
Anonymous
Not applicable

 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

0 Likes
Reply
Anonymous
Not applicable

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.

0 Likes
Reply
Anonymous
Not applicable

 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

0 Likes
Reply
Esteemed Contributor II

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

0 Likes
Reply
New Contributor

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

0 Likes
Reply
Esteemed Contributor II

@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

0 Likes
Reply
New Contributor

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

0 Likes
Reply