SRAM continually failing at certain addresses

[snarkysparky]

I am writing a 512k X 16  SRAM as fast as I can with a SAMD51P.

So I wrote a memory test program that writes all addresses with the address itself and then reads back to check.

I continually get failures at certain addresses.  Writing the first 100k addresses There are

about 7 that will have incorrect values.

I would think that if I was writing too fast the errors would be more randomly distributed.

If I write the same value to all addresses I get no errors.  What could be different at certain address in SRAM chip?

Do I have a bad SRAM mounted on my board ?

[NorthGuy]

I would think that if I was writing too fast the errors would be more randomly distributed.

If you try writing/reading slower you will immediately find out if the problem is speed related or not.

Otherwise, if you want someone to figure out the reason for the pattern, you need to post the exact addresses, exact values you read (are the values you read always the same too?) etc.

[snarkysparky]

I slowed the clock speed with no change. Still error.

I increased the drive strength of the port driving the data lines.   For samd just set PINCFG.DRVSTR for each pin.

That seemed to work.  Still worry about why just some addresses.

Maybe i am fighting the data lines of the SRAM.  I though they would be HI Z since i have OE  pin high.

I am using PORTA for Address and PORTC for Data.   SRAM is asynchronous parallel interface.


Thanks

[kfnight]

If it depends on the value it could be ground bounce.

[thm_w]

Oscilloscope capture and photo of the board would be interesting to see.

[Daixiwen]

Do you always have the fails at the same addresss? And if yes, if you write with a different sequence (going down in address values instead of up for example) does it still fail at the same addresses?
You could have a short between two address lines, but then I think there would be more than 7 locations with fails.

[Doctorandus_P]

If you connect the databus to the address bus, then it will readback without errors.
No SRAM chip needed. 

[snarkysparky]

The errors are mostly in values that have just switched a bunch of bits off.   tranasition from 0b011111..  to 0b100000...

Like

0b1000001100000.

the red 11 don't belong.

I think it is a crosstalk issue.  I have extended the delays between transitions with no effect.

Gonna check my write enable line for noise.

Thanks

[RoGeorge]

If the issue is caused by the signal's edges being too sharp, lowering the reading peace won't help.

Some series resistors on the address bus might help (to lower reflections and ringing).  Do you have them already in the design?

[Evan.Cornell]

If the issue is caused by the signal's edges being too sharp, lowering the reading peace won't help.

Some series resistors on the address bus might help (to lower reflections and ringing).  Do you have them already in the design?

Or lower drive strength of the pins, if MCU supports that?

[AndyC_772]

I think we need to see a good clear photograph of your board, and your schematic.

If changing the drive strength of the I/O pins does make a difference, and lowering the clock speed doesn't, then you have a signal integrity problem. This could be any of a number of things - poor topology, incorrect termination, ground bounce, poor supply decoupling and so on.

[Cerebus]

The errors are mostly in values that have just switched a bunch of bits off.   tranasition from 0b011111..  to 0b100000...

Like

0b1000001100000.

the red 11 don't belong.

I think it is a crosstalk issue.  I have extended the delays between transitions with no effect.

Gonna check my write enable line for noise.

Thanks

That looks like ground bounce. You're switching a lot of bits at once and that's rapidly altering the amount of current through that particular MCU port. I'd hazard a guess that if you ran a memory test with both the addresses and data in gray code (only one bit changing between sequential values) that you'd get a perfect pass.

If it is ground bounce you can probably solve it by better decoupling of the supply to the port that's causing the problem, or to the whole part if you don't have multiple Vdd/ground pins. You may also need better supply/ground planes.

As others have said - pretty hard to diagnose without schematic, board layout and some scope traces of all the suspects (Vdd/ground in various places, failing data lines etc.).

[AndyC_772]

Decoupling won't help if the problem is a shift in ground potential between the CPU and RAM. The only effective cure is to reduce the GND inductance between the two, which is best done with a solid, unbroken ground plane.

[Cerebus]

Decoupling won't help if the problem is a shift in ground potential between the CPU and RAM. The only effective cure is to reduce the GND inductance between the two, which is best done with a solid, unbroken ground plane.

I'd include that in "decoupling". "Decoupling" is just shorthand for keeping your signals out of your power supply - decoupling signals and power, making them singular again - and 'ground' is part of your supply. Decoupling doesn't just mean "throw a capacitor at it".

If it is ground bounce you can probably solve it by better decoupling of the supply to the port that's causing the problem, or to the whole part if you don't have multiple Vdd/ground pins. You may also need better supply/ground planes.

[NorthGuy]

I have extended the delays between transitions with no effect.

If this is a asynchronous memory chip then giving enough delays should give time for the signals to settle, no matter how bad the SI is. There must be a timing diagram in the datasheet which lists all the timing parameters you need to meet. If you have SI problems, you will have to make these parameters longer. You need to figure out what parameters are vioalted. E.g., if you have problems with transitions on the address lines affecting data, you probably should wait longer (possibly much longer) between setting the address and releasing WE (when you write) or between setting the address and sampling data (when you read). But eventually it should work.

[snarkysparky]

Here is the section of the board showing memory and samd.  It is a four layer board with order  top -> ground plane -> 3.3v plane -> bottom signal.

ground is highlighted.

[Doctorandus_P]

On a more serious note:
I assume you have a (nearly) continuous GND plan on the inside layers, and decoupling looks adequate, at least if that square chip (SAMD51?)has sufficient decoupling caps on the back side of the board.
Have you considered that you can interchange all address lines, and all data lines to accommodate layout?

Getting it to work is not a question of just lowering some clock signal, or writing slower.
You have to carefully check that all control lines are toggled in the right order, and also verify the setup and hold times of the read and write lines to the SRAM.
I assume the SAMD51D does not have an external memory interface, and you're driving the SRAM with software.
I do not know the speed of your SRAM chip, when I toyed with these setup times of some 70ns to 120ns were "normal".
In the critical sections you may need to insert significant delays to slow a quick uC down enough to get it to work reliably. Start by writing a small delay function or macro which inserts a bunch of nops or a delay loop, and ensure that the timing is at least 10 times slower then what the datasheet tells you. This should be enough to simply wait out GND bounce problems.

Usually uC's have synchronization mechanism on the output pins that can add an extra clock cycle or 2 on both reads and writes. A critical section here is the delay between toggling the read line to the SRAM and reading in the data. It's likely that the uC's outputs are updated at the end of a synchronization cycle, while the inputs are latched at the start of the next synchronization cycle.

Your mention of:
" Maybe i am fighting the data lines of the SRAM.  I though they would be HI Z since i have OE  pin high."
is also a bit dubious.
You should check such things carefully, so read the datasheet, and make sure you do it right.
Use the timing diagram from the datasheet, and compare it with your software.
When in doubt, slow the stuff down by a factor of 10 or so.

Leaving the databus floating during a part of the transaction is not a good practice. It may help to add some pullup or pull down resistors to the databus. Have you ever heard of "meta-stability"? The syncronisers on the uC side are to prevent problems with this, but the SRAM chip is unlikely to have these. If some part of the chip enters meta-stability, due to invalid voltages on the databus at the wrong time, then it may take a long time to recover from it.

At the moment my guess is that some part (Either on read or write) is marginal, and changing lots of bits adds a bit of ground bounce or other noise which lifts it just over the edge.

[snarkysparky]

The app engineers at ISSI fixed my trouble.   I was changing things at the wrong time relative to write enable.

The timing diagram isn't very clear.

Now I can write and read the whole memory with only one fault.  and it is consistent.

Address 75712    wrote 10176   read back 10175

10176 =  10011111000000
10175 =  10011110111111

Something wrong with SRAM maybe.  It could have been static damaged.

May try another NOP instruction between write enable changes.

Thanks

[bson]

What's the SRAM input capacitance?  What is the µC bus output resistance?  What rise time are you aiming for?  This will tell you if you need additional series resistance to keep things nice and quiet.

For example, if the µC has Ro = 20Ω, the inputs on the SRAM are 8pF, and you have a 3.3V high level,

Vth = 3.3/2 = 3.3*(1-exp(-t/RC))
=> t/RC = -ln(1-1/2)
=> RC = t/0.69

Targeting for example a 2ns transition time (low to threshold, or high to threshold),
RC = 2.9nΩF

With C = 8pF, you get R = 362Ω.  You have Ro = 20Ω, so you'd need to add ~340Ω.
If Ro = 200Ω, add 160Ω.

This is just ballpark, and it's not super critical, so if you have say 100Ω resistors somewhere else, that's probably fine too.

Then stick a low-capacitance probe on the input pins and measure the 0-1.65V rise times to verify, and inspect for overshoot, ground bounce, ringing, or any other crap that doesn't belong.  Putting a 10pF probe on an 8pF pin probably is going to hide problems and you're better off going "by the numbers" and trusting those more than what you see on the scope as the rise times will drop significantly with an additional 10pF.  But if you see problems with a 10pF passive probe you know you have a must-fix issue.

A lot of modern logic has 3-5pF input capacitances, and modern µC's have the characteristics of modern logic (I've found 74LVC is often a good approximation).  Note that modern logic often has a maximum rise time to prevent metastability.  Make sure to go over the SRAM electrical specifications and make sure you understand them, how they matter or impact your design, and how to verify each one of them.

This is in the conceptual category of "circuit correctness".  Layout is secondary, especially with tiny boards.

A weaker drive is a good idea if an option, and will effectively increase the output resistance.  But you still need to do the math.