Are you serious?
Does it mean we should stop using PSoC5?
How do we know our project doesn't have this problem?
Could Cypress support confirm this?
Something sounds a bit fishy here...
If you are only passing the address of the array, thats just a pointer being passed around. The compiler will only push 4 bytes to the stack, not the full size of the array. So sounds like something is not right here!
Well, you trust in your car that it works, you trust in the airplane you use and you ought to trust in the compiler you usually use.
When something goes amiss you can be sure that in more than 99.99 percent of the cases it is your mistake (normally it takes you some corrections and a re-build).
When searching for the reason of an issue you'll find it probably in your part of the system. If not, you can be darn sure that you exceed any limits within your code let it be stack, heap or parallel access of a variable from an interrupt procedure and from code.
There are some VERY surprising behaveours in PSoC3 caused by strange compiler needs for the strange core, but they have been documented although rarely red.
For PSoC5 there is a Gnu CC used about which you can say that in every cellphone in the whole wide world more or less code was compiled by that.
Having a bug like that one you mentioned would have been detected (and corrected) earlier or was it confirmed by ARM to be a compiler bug?
I am using constantly structures like linked lists, using memory from malloc() which all are including pointers in function parameters and since I am not a friend of global vars (when in need I try "static") but I've so far not come to any errorneous behaveour yet.
If you are willing to analyze a bug like that, I would try to cut-down the program to the smallest version that shows the error and post that project here, so that we all might have a look at, I am quite optimistic that we could find something...
Apologize for not clarifying things here earlier. You have nothing to worry about PSoC 5 compiler. Later figured out that I was doing something wrong in my code . I was doing some wrong arithmetic operations on the array pointer for accessing the array elements which ended up in accessing memory locations beyond the array boundary. Bottom line - Take special care while dealing with pointers in your code!!
Working on code compression in a design I gained a lot in the
code size by passing pointers to longs, a little less to ints,
vs values. In a 32 K design ~ 1.2K gained. Of course speed
was enhanced as well.
Note passing pointers to native machine size, 8 bits (PSOC 1, 3) ,
sometimes bloated code.
On the issue of Compiler reliability, I always think of them as a work
in progress. I have had fairly mature compilers choke on compound
typing of calls, and sometimes bloat a simple task with an api. I have
not yet had the opportunity to work with a compiler whose bug list is
And from one compiler to another, even for same architecture, code
density can be quite disparate.
Wiping the sweat from our brows!!! Thanks for a feedback.
Pointers in PSoC3 can get weired, depending on their definition they are 4 or 3 bytes long and they may even as I remember be as short as 2 bytes. Yes, I admitt, I grew up in the age of 80xx micros but I never was a friend of the 8051 architecture..