PSoC Creator 3.0

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Hi,

   

Is anyone else having strange problems with PSoC Creator 3.0?

   

void main() is getting a warning that  "return type of 'main' is not int". I pretty knew that when I wrote the program.

   

Also, as I move down the module, the first subroutine after main() is being treated as a function call or a prototype, I can't tell. It's full error, not a warning. It's says it's looking for a semicolon. I already have a prototype at the top of the module.

   

It doesn't seem to me that an upgrade to the compiler should cause hard errors on a program that would previously build with no errors or warnings.

   

Nick

0 Likes
1 Solution
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

All the examples you brought up where actually cases of unsafe code before. With the compilers advancing, and needing to generate tighter and faster code, such code can actually lead to more bugs (because the compiler then assumes things which aren't true).

   

The ISR you mentioned which didn't work after you removed the warning: care to share the code?

   

Regarding the const char *- yes, the compiler is right. 'const char *' defined a pointer to a constant char array, meaning this array of characters is thought to be never changed. If you now hand over this pointer as a 'char *', it suddenly is now mutable, and any code getting this pointer is free to do so. Thats why the compiler warns you about that. (and thats the reason why the first argument of memcpy isn't const, but the second is - this function guarantees not to modify its source. If the second parameter wasn't const, memcpy would be perfectly allowed to screw around with the data there).

   

I once read a book about 'bug free C programming' (an oxymoron in itself, I know). It had a list of all the code which will get accepted by a C compiler (because the standard allows it), but which is unsafe or even undefined. The list was in 6pt font and about 15 pages long or so. And each item of this list, when in a program, can lead to a bug (and be it just because the compiler handles it differently after an update, or for some other reason).

View solution in original post

0 Likes
55 Replies
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Some more nice examples...

   

What's wrong with this code? (And what happens?)

   
enum {N = 32}; int a, pfx; void prefix_sum (void) {   int i, accum;   for (i = 0, accum = a[0]; i < N; i++, accum += a)     pfx = accum; } 
0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Well, if this is the route you're taking, we may have to look elsewhere for hardware.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Well, if you judge the capabilities of a tool by its user...

   

I'm just a volunteer here, a PSoC user, not a Cypress employee. All of us here try to help you to get the most out of PSoC, and to avoid any problems. We want everybody to succeed.

   

If you think that a compiler flagging dubious code goes in your way, and is of no help, then disable the warning. Cypress (or was it Keil?) already explained how to do that. I for myself find these always useful. And I have found my share of _real_ bugs that way.  But YMMV.

0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

-Nick

   

Depending on how long one already programmed in C one has spent HOURS in searching for a bug he made that has not been flagged by the compiler. As you know there is "lint" to overcome this need giving at some places hints where the code might lead to errors. Who is to blame? Well, there are some places where C-compilers differ in the way statements are evolved to be executed. A common example is to have a variable incremented and used in one statement as

   

 

   

MyArray[ii] = ii++;

   

 

   

Since it is not defined (they have simply forgotten to) one compiler may result in

   

 

   

MyArray[ii+1] = ii; ii ++;

   

while another compiler might generate code as

   

MyArray[ii] = ii; ii++;

   

 

   

So, when you write down a construct like the above you will be very content when hinted to that fact. Now you get hinted throughout your (flawlessly running) program and get upset which I fully understand, but why don't you accept the fact that there can be some ambiguity and that a future change in the compiler might stop your program from running. Why don't you swallow that frog and go through your program and change that 200 lines to something that will be correct even when you switch to a PSoC5 with the GCC which is in my opinion more critical with warnings than the Keil.

   

 

   

Bob

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Just as hint: one might think that in the code I posted there is just a memory access one member behind the defined area, which might not be too bad. But actually on PSoC5, which uses GCC, this might get optimized into an endless loop, because the compiler optimizes away the loop condition completely.

   

For a better explanation of a related problem (which caused real security problems) see this LWN article. I guess I should never use pointers again 😞

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

@hil, please stop posting on this thread. You're just arrogant and you are not grasping the problem.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

@bob: nitpicking: its not undefined, but unspecified. The standard (at least the newer ones) are explicit. There are 3 parts of that statement - a) de-referencing the array (MyArray[ii]), b) getting the value 'ii++', and c) the assignment. The standard guarantes that a and b happend before c, but their order is left to the compiler (so it can optimize at will in wich sequence sub-expressions are evaluated).

   

Undefined would mean the program could also invoke nasal demons - and it would still be correct:)

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Btw: I would have thought the code correct - I thought that the i++ would be guaranteed to be executed as last part, after the assignment. And then I would have wondered why e.g. a higher optimization level, or a newer version of the compiler would break the program (and in subtle ways, and not visible in the debugger probably)...

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

I work for a company that sells products in the real world. It is our livelihood. We have developed a new line that must behave like our legacy products only in a smaller physical package. The PSoC 3 was chosen by the hardware developer. The hardware developer has a one sub-routine test program that verifies the hardware. My job is to write the product program that interfaces to customer machines and their programs.

   

Much of the code has been re-used and has been working across 3 different microcontrollers and 3 different compilers.

   

I used the PSoC 3 Developer Kit (CY8CKIT-030) to write my program while the hardware designer worked on the first pass hardware. I began using PSoC Creator 1.0 and eventually both the hardware developer and I got on the same page using 2.0 and then 2.2. I integreted his code with mine and we proceeded to release prototypes to our customers for evaluation. We are mid stream in the development.

   

The hardware engineer upgraded to PSoC 3.0 and I attempted to do the same. To be on the safe side, I do my development on a laptop but keep a desktop computer in sync with the laptop in the event that the laptop crashes. When I tried to compile the program that compiled with no errors or warnings in 2.2, there were 2 days worth of work in clearing up the warnings and ultimately, the program ceased to work in our product.

   

That you must recast a stack variable as a const on a stack is the least of my worries at this time. The point is, Cypress and their partner Keil have collapsed legacy code AT A  RANDOM POINT IN TIME WITH NO FOREWARNING.

   

The changes to make the warnings stop increased the code slightly, so the argument that after all this time, compilers need to be produce tighter, more efficient code doesn't apply to PSoC 3.0 and Keil's latest version therein.

0 Likes
HeLi_263931
Level 8
Level 8
100 solutions authored 50 solutions authored 25 solutions authored

Oh, I understand the problem you are having. Its just my take on this that I think you are chasing the wrong problem.

   

First of all, neither Cypress nor Keil destroyed your working code. After all, it worked (as per your statement) after compiling with Creator 3.0 (since you tested it). But the compiler told you that you were using potentially error-prone code, which might break. And in trying to fix these warnings, the code broke. I guess this happens (as I have experienced multiple times), thats why I was asking about the code in question (you mentioned an ISR which, after changing to code to be warning-free didn't work), and I wanted to help you to find out why.

   

When I read your finding that just disabling the warning you were annoyed about changes/increases the code size, I get the impression the the compiler then needs to disable certain optimization to ensure that the program really does what it should...

   

Btw: I like your take on having an automated test for your product, because it really helps you to catch such problems easily.

   

I'm also a developer working for a company selling real products. In fact, our product helps other companies selling product. So there really depends money on my work (fortunately not lives, I don't know if I would take that risk). Thats why I'm concerned, day by day, to be sure that my code does what I want it to do (and not what the compiler thinks it should do).

   

Having said that, I really should go to bed now 🙂 You seem to have find a solution you can live with, and thats perfectly fine.

0 Likes
ScEn_283436
Level 5
Level 5
5 sign-ins First solution authored 100 replies posted

Hey Bob, I did go through my code and clear up all the warnings. Now it doesn't work.

   

Thanks for you help.

   

Have a nice day.

0 Likes
ETRO_SSN583
Level 9
Level 9
250 likes received 100 sign-ins 5 likes given

In earlier post reference being made to turn off warnings.

   

 

   

That sure looks like a product liability case to me. A public safety issue ? Not being

   

a compiler expert this sure looks like a huge problem to my work. Users needing to

   

defeat compiler definitions with their own .h files, does that imply one would have to

   

have an insight into C that transcends a "normal" embedded engineers training,

   

experience ? Casts with inconsistant or undefined results.

   

 

   

Holy crap, how does NASA or a medical device firm handle this problem ?

   

 

   

This thread Nick has raised deserves senior management attention one would think.

   

 

   

Regards, Dana.

0 Likes
Anonymous
Not applicable

Dear all,

   

After the migration of my PSOC3 code from Creator 2.x to Creator 3.0, and I have 2 kind of new remarks („red signature on the left”), which I cannot eliminate.

   

The first:

   

I have 2 bit-addressable global variables. Each defined as follows:

   

bdata int CM1;

   

sbit CM1_S07 = CM1 ^ 7;

   

sbit CM1_S06 = CM1 ^ 6;

   

sbit CM1_S05 = CM1 ^ 5;

   

sbit CM1_S04 = CM1 ^ 4;

   

sbit CM1_S03 = CM1 ^ 3;

   

sbit CM1_S02 = CM1 ^ 2;

   

sbit CM1_S01 = CM1 ^ 1;

   

sbit CM1_S00 = CM1 ^ 0;

   

The remark is “type specifier missing, defaults to int”. What is the problem with this definition? I have not remark before Creator 3.0, and the program is still functioning.

   

The second:

   

I have my interrupt handler routines in the main function. They look like:

   

CY_ISR(vectorCountPos_M1)          

   

{

   

// code is written here

   

}

   

But I have the remark, which “expected function body after function declarator”. What is the problem here?

   

Anyway, the program is still functioning, but I do not understand these new remarks. Can anyone advise me?

   

 

   

Best regards,

   

Frankee.

0 Likes
lock attach
Attachments are accessible only for community members.
alli_264371
Level 4
Level 4
25 replies posted 10 replies posted 10 questions asked

Maybe anyone know why component catalog has removed from the PSOC Creator3?


I cannot confirm email and add messages due to a bug on your site, the email section is not active
0 Likes
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

@Frankee, @Maagalex,

   

It is normally not advisable to hijack a thread for your own use. Better is to start a new one, so it is easier to answer your questions directly.

   

Maagalex: I never saw that before. De-install Creator and re-install it again to make sure there was no error before.

   

 

   

Frankee: There are some known flaws in the in-time compilation which will be corrected with the next revision, so I was told.

   

Stick to warnings and errors from the compilation and ignore the flagged statements.

   

 

   

Bob

0 Likes
RobynW
Employee
Employee
5 likes given First comment on blog 10 likes received

@maagalex   If you click on TopDesign.cysch, I think you'll see the full component catalog again.  The catalog doesn't display when your in the code editor - only in the schematic.  I will ask our design team to put a better error up.  This one isn't very helpful.  -Robyn

0 Likes