RAM corruption [solved]

[avatarengineer]

PICC 5093 & 5094

Found a For Loop goin out of bounds overwriting data in following addresses,
but no compiler error reported.

[Ttelmah]

I've used the K40, & the K42, many times without any sign of such
corruption. Have to wonder what is actually going on.
Have seen odd issues like this in the past when people are not connecting
all the Vss/Vdd pins or have inadequate smoothing close to the chip.
Describe carefully the hardware actually involved?.

[avatarengineer]

For loop over ran assigned struct data area, uncaught in error reporting.
I found the only solution was
#reserve data space above assigned data space
until the code error was found.

[temtronic]

I don't use that PIC, but... have you tried putting
#zero_ram
in your code ??

[avatarengineer]

yes,
zeroram is in code.

[temtronic]

hmmm, I wonder if you run it twice, does the problem 'magically go away' ?

It seems like only a small 16 byte 'bank' of RAM is 'bad'. Can you run a test program to find out if each bit of those bytes fails or a specific 'pattern' ?

Seems odd to me that just 16 bytes somehow fail.It could be a bad design within the die, or how the PIC accesses that part of RAM.

Perhaps there's another PIC that will work for you ? I'd definitely contact Microchip about it !!

[PCM programmer]

I would compile it without the #reserve statement, and look at the .SYM
file to see if 0x220:0x22F is used by more than one variable.

I would check if there is an array just before it in memory. Maybe that
array is being written beyond the end.

I would check if there are scratch variables used by the compiler that
are just before that region. Maybe the data type used by CCS is too
small. (Or a data type used by you).

I would look for problems like this.

[Ttelmah]

Also walking 'before' the start of an array.
So any arrays just below or just above this range.

[Gabriel]

I'm using this pic as well.
I've had no issues YET.
I would check for all the recommendations listed here first.
Then, when the problem shows up, do a Power Reset and see if it goes away.. might need more than 1 reset.

If it does goes away, then its the silicon issue listed on the errata, otherwise, the items listed by the other members are the most likely cause. As Jay mentioned 16bytes seems too little to be the ram issue listed on the errata.

Notice that the recommended tests for detecting the issue cover a wide range of memory rather than specific 16bytes.

That being said, i will make a note of your suggestion.
Later today ill post my fuse/osc settings, please share yours and lets see if the problem goes away.

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

[avatarengineer]

My code error in a for loop accessed an area beyond an array.
I was complacent in expecting the compiler error checking to find my error.

Lessons learned, any SRAM area can be corrupted when accessing an array beyond its assignment.

[dyeatman]

That's the one big thing I learned when I started programming in C. Most
compilers don't do a range check for that. Got myself a few times before I
learned to double check those things.
_________________
Google and Forum Search are some of your best tools!!!!

[Ttelmah]

Glad you have found it.
No the compiler does not range check. That is why the 'old hands' here
immediately said to use the symbol file and check what is just before and
just after this area, and then triple check the ranges used to access these
areas....
If you think about it, with the PIC, there is memory protection hardware,
so range checking, would involve the compiler in having to perform every
possible calculation with every possible value for array accesses. Not going
to happen I'm afraid.
C++, has limit checking as part of the language. C does not. Even on
Microsoft C, I've seen array accesses beyond the allocated size, cause
problems....

[Gabriel]

Just as due diligence: