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 CCS Technical Support

SRAM test

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



Joined: 26 Sep 2020
Posts: 72

View user's profile Send private message

SRAM test
PostPosted: Tue Jul 01, 2025 11:45 pm     Reply with quote

Are there methods for testing RAM in PIC18 microcontrollers?
I encountered a problem with RAM write and read errors. Then I manually assigned cells for some variables and the problem disappeared. At first, I associated this with the power supply. But when powered from a laboratory source, the problem did not disappear.
The document PIC18F27/47/57Q43 Silicon Errata and Data Sheet Clarifications mentions similar defects. It is not entirely clear how the RAM testing program works. And why, if such a defect exists, do these devices go on sale.
Ttelmah



Joined: 11 Mar 2010
Posts: 19878

View user's profile Send private message

PostPosted: Wed Jul 02, 2025 7:21 am     Reply with quote

Simple RAM testing is easy. You just walk through the memory (using a
few cells at some location for your variables), and write every possible value
to each cell and then read it back. If there is a difference then you have a
problem. You can also write a value to a cell, and then try writing values
to the adjacent cells and see if there is a problem with this.
Cells can also become corrupted with power spikes and radiation.
However 'faulty' cells generally should not exist, but one in a billion times
there will be a chip with problem. Chips are only ever 'sampled', not 100%
tested.
In the case of the PIC18F27/47/57Q43m it is actually an oddity
of the power sequencing that causes it. Power up another time, and it'll
work OK. This is why it did not get spotted initially..... :(
For this chip, the failure is simply that a cell is written with a non zero
value, and returns zero, so the test just involved writing and testing for this.
However there have been individual faulty chips where a problem only
occurs. with particular patterns of data, and it is not found till later. There
have also been been documented cases of chips that MicroChip rejected and
scrapped being 'salvaged' by unscrupulous people, and given false (but
apparently legitimate) markings, and sold.
If you have a number of chips with a problem you need to talk to MicroChip,
and give them the batch numbers.
temtronic



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

View user's profile Send private message

PostPosted: Wed Jul 02, 2025 10:47 am     Reply with quote

sigh, RAM tests.. reminds me of the early PC days. Would take HOURS to run RAM test on 640KB PCs. From what I recall.... zero all of RAM, confirm, fill 0XFF in all of RAM, confirm. do a 'checkerboard and confirm. then a few other tests. Some of these would point out bad PCB traces. Today nobody does RAM testing...hate to think how long it'd take !

My 'gut' thought about maybe no .1 caps near the PIC, maybe all VDD, VSS pins not connected as required, a 'slow' power supply.... yeesh, if it's truley 'internal' not much you can do, except get a different batch of PICs ??
dmitrboristuk



Joined: 26 Sep 2020
Posts: 72

View user's profile Send private message

PostPosted: Thu Jul 03, 2025 12:01 am     Reply with quote

I ran the RAM test (00, FF, AA, 55), no errors. Additionally, I saved a RAM dump in the program memory and read it through the programmer, no errors either. There are even more questions. However, it should be noted that the test is done through indirect addressing, and my program does not use it. Also, there are many bit operations. At the same time, manual assignment of registers helps. Most likely, I was sold counterfeit devices.
Ttelmah



Joined: 11 Mar 2010
Posts: 19878

View user's profile Send private message

PostPosted: Thu Jul 03, 2025 7:04 am     Reply with quote

Honestly the most likely thing is you have a memory leak.
Classic fault. You have something like a string (character array in C), and
you write to a location beyond it's declared size. Result the memory cell
beyond the end of the array gets corrupted.
Any code involving pointers has this risk.
On your original code (without the variable relocation), add a dummy
variable in front of the ones getting damaged. Put a value into this, and
test at intervals for this changing. If it changes, study the code just before
this happens. Look in particular at pointer accesses, string and array
accesses.
It is a very common fault, and thousands of times more likely than
a hardware problem.......
temtronic



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

View user's profile Send private message

PostPosted: Thu Jul 03, 2025 7:15 am     Reply with quote

I've always been amazed that someone CAN make counterfeit chips ! Really it has to be expensive to reverse engineer and make them ??
dmitrboristuk



Joined: 26 Sep 2020
Posts: 72

View user's profile Send private message

PostPosted: Thu Jul 03, 2025 11:18 pm     Reply with quote

Ttelmah I have not used pointers in the program. The simplest code. Yesterday I did some more tests. There is a problem at the ALU level. Filling the RAM bank with numerical values ​​via the movwf and bcf (bsf) instructions gives completely different results. However, when filling the RAM via indirect addressing, no errors occur at all.
temtronic There are no problems with power supply, a laboratory source was used, power supply capacitors are present.
I meant rejected chips that did not pass the test, but were packaged and sold through unofficial channels.
Ttelmah



Joined: 11 Mar 2010
Posts: 19878

View user's profile Send private message

PostPosted: Fri Jul 04, 2025 4:06 am     Reply with quote

Contact MicroChip, with the batch number and manufacture ID of the chip.
They will be able to tell you if this is a known fault.
Log into your MicroChip account (if you do not have one register for this),
and report it via here.
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