 |
 |
View previous topic :: View next topic |
Author |
Message |
dmitrboristuk
Joined: 26 Sep 2020 Posts: 72
|
SRAM test |
Posted: Tue Jul 01, 2025 11:45 pm |
|
|
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
|
|
Posted: Wed Jul 02, 2025 7:21 am |
|
|
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: 9501 Location: Greensville,Ontario
|
|
Posted: Wed Jul 02, 2025 10:47 am |
|
|
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
|
|
Posted: Thu Jul 03, 2025 12:01 am |
|
|
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
|
|
Posted: Thu Jul 03, 2025 7:04 am |
|
|
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: 9501 Location: Greensville,Ontario
|
|
Posted: Thu Jul 03, 2025 7:15 am |
|
|
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
|
|
Posted: Thu Jul 03, 2025 11:18 pm |
|
|
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
|
|
Posted: Fri Jul 04, 2025 4:06 am |
|
|
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. |
|
 |
|
|
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
|