CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

RAM corruption [solved]

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
avatarengineer



Joined: 13 May 2013
Posts: 51
Location: Arizona

View user's profile Send private message Visit poster's website

RAM corruption [solved]
PostPosted: Mon Aug 10, 2020 11:44 am     Reply with quote

PICC 5093 & 5094

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


Last edited by avatarengineer on Tue Aug 11, 2020 9:06 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Mon Aug 10, 2020 12:22 pm     Reply with quote

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



Joined: 13 May 2013
Posts: 51
Location: Arizona

View user's profile Send private message Visit poster's website

SRAM issue work around [solved]
PostPosted: Mon Aug 10, 2020 12:34 pm     Reply with quote

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.


Last edited by avatarengineer on Tue Aug 11, 2020 9:09 am; edited 1 time in total
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Aug 10, 2020 2:04 pm     Reply with quote

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



Joined: 13 May 2013
Posts: 51
Location: Arizona

View user's profile Send private message Visit poster's website

RAM corruption
PostPosted: Mon Aug 10, 2020 3:50 pm     Reply with quote

yes,
zeroram is in code.
temtronic



Joined: 01 Jul 2010
Posts: 9081
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Aug 10, 2020 4:33 pm     Reply with quote

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



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Aug 10, 2020 7:00 pm     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Aug 11, 2020 1:10 am     Reply with quote

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



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Tue Aug 11, 2020 4:57 am     Reply with quote

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



Joined: 13 May 2013
Posts: 51
Location: Arizona

View user's profile Send private message Visit poster's website

Mea Culpa
PostPosted: Tue Aug 11, 2020 9:13 am     Reply with quote

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.
Embarassed
dyeatman



Joined: 06 Sep 2003
Posts: 1910
Location: Norman, OK

View user's profile Send private message

PostPosted: Tue Aug 11, 2020 10:37 am     Reply with quote

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



Joined: 11 Mar 2010
Posts: 19195

View user's profile Send private message

PostPosted: Tue Aug 11, 2020 11:16 am     Reply with quote

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



Joined: 03 Aug 2009
Posts: 1067
Location: Panama

View user's profile Send private message

PostPosted: Tue Aug 11, 2020 6:17 pm     Reply with quote

Just as due diligence:

Code:
#include <18F47Q43.h>
#device PASS_STRINGS=IN_RAM
#device adc=10
#fuses MCLR
#fuses NOWDT
#fuses NOLVP
#fuses NOXINST
#fuses NODEBUG
#fuses NOPROTECT
#fuses HS
#fuses RSTOSC_EXT_PLL
#use delay(clock=64MHz)


Code:
setup_oscillator(OSC_EXTOSC_PLL|OSC_CLK_DIV_BY_1|OSC_PLL_ENABLED|OSC_EXTOSC_READY);


I got a 16MHz crystal onboard.

These are my fuse/osc settings which seem to not present the RAM issue as of yet.

If you encounter the RAM initialization issue please let me know... try these settings and see if it goes away.
_________________
CCS PCM 5.078 & CCS PCH 5.093
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group