EEVblog Electronics Community Forum

Electronics => Projects, Designs, and Technical Stuff => Topic started by: alank2 on March 03, 2018, 01:00:56 am

Title: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 01:00:56 am
I switched to a larger 512K SRAM (IS61C5128AL-10TLI) from a slower smaller one (128K, 55ns).

I am controlling it with the memory interface on an ATMEGA64.  It uses ALE to latch the lower addresses (A0-A7) from the data pins.  Using an 74AHC573, was using an 74HCT573, both exhibit the same issue.

I am running through a simple 3 pass memory test on the AVR.  If it fails, I get a bank, address, what it should have been and what it was read as.  It does a pass 1 where it writes 0x55 to all 512K, then a pass 2 where it reads it back and verifies it is 0x55 and then writes it to 0xAA, then a final pass 3 where it verifies it is 0xAA and then writes it to 0x00.

Some really odd stuff:

If I read the value a second time, third time, fourth time, it will ALWAYS be correct.  It is correct in the SRAM.  But it is NOT correct the first time when the error occurs.  Where it is going to occur is very random.  It might make it fine and report no errors.  It might find the error early on in bank 0 or 1, it might find it later in bank 11.  (32K banks).

A very odd thing is that pass 2 always completes.  I've never had it fail to complete pass 2 and pass 2 is a VERIFY pass.  I figured that the test of 0x55 was always true and I'd swap it so it does 0xAA first, then 0x55 second.  I figured this was make pass 2 be the failing pass.  It does not.  It will still always run pass 2 just fine and fail on pass 3.

It did seem to have something to do with latching because when I connected my Saleae Pro 16 to it, just having its pin connected seemed to change the behavior and make it fail less at first.  So I replaced the jumper and then it didn't seem to make as much difference.  Sometimes when you connect a logic analyzer lead, the difference electrically can make a difference in how it acts.

It wasn't failing at an even address before, but now the final 4 bits are always zero.  If it is going to fail, it will be at address 9ac0, ea90, f1c0, 9290, etc.

I'm using pin leads that have a flexible wire on my breadboard instead of the traditional colored wires, perhaps this is part of the problem.  Still, I find it odd and wonder if it is an IC issue with the SRAM.  The reason is that on the second read it works fine.

Take a look at the capture I've attached.  I've only got D0-D3/A0-A3 hooked up with the OE/ALE.  The top OE shows to read pulses.  You can see the ALE latching the data into the address lines properly.  Again, latching a "0" into the address bus twice.  The first memory read is 0xF (failure) and should have been 0xA.  The second read (where the cursors are) shows that it did indeed read correctly on the next read pulse.

Any ideas what could be going on that I should check?

I've tried all the different wait states, no difference.  I've tried enabling the data lines bus keeper, no difference.

The SRAM is fast, requiring no more than 10ns for address setup times, etc.  They look plenty large at 60-100ns.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 03:13:33 am
I changed to traditional breadboard wiring - problem persists.

I went ahead and stopped using the AVR memory interface and bit banged it.  This works.

I read some things in the datasheet about timing, though everything looked good in the LA, so I dropped the speed to half (7.3728 Mhz) and then quarter (3.6864 MHz).  Same results - the memory interface fails, but the bit bang works.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 03, 2018, 07:56:32 am
Hi Alank2, I'm not familiar with the SRAM but have what may be some obvious ideas from a general debug standpoint.

If the memory works when you bit bang vs using the sram peripheral on the ATMEGA then we know the problem resides with either how you are using the peripheral or some difference in your code between the bit-bang version and the peripheral version.

I can see you have the ability to do a multi channel probe on all the lines I think this will show you the differences if their were any.

The peripheral will have some setup and timing requirements and flags being set when transfers / operations are complete you are testing against all of these as per the datasheet?. Did you say that everything worked perfectly for you with the "slower smaller one" and that only when you switched to the new "fast" one things started going wrong?

I don't think we can presume that the faster one is just going to work out of the box because the slower one did. It's not wise to make such a presumption - and I'm not saying you did just something to consider.

You mentioned that the first verify fails but all subsequent ones work. This makes me think you have something wrong with how you initialize your input buffer? or the mega peripheral itself.

Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 07:14:15 pm
Thanks David.  I tried a few more things this morning, but it just doesn't make sense as the signals look good, but yet it brings the wrong data.

I finally decided to swap the part with another new IC.  After some hot air and resoldering, this made a huge difference.  It ran 10 tests solid before it failed when I moved near it.  If I stay away from it, it runs perfectly, but if I hover my hand over it, it will fail pretty soon.

I guess I'm not sure what to think.  The IC swap seemed to fix it.  I'm not sure if the other IC was defective or perhaps it had a bad connection t the DIP adapter, but it looked beautiful.  Maybe this is too much to ask for a breadboard.  The OE pulse is usually 60ns.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 07:25:29 pm
Switching it half speed brought back the problem.  I guess it was not the IC.  It works much better than the other one at full speed, but at half speed (7+MHz) it fails every time.  It is frustrating.

One weird thing is that the datasheet talks about different modes like leaving the OE enabled all the time for some odd reason.  But it also shows it working how you would expect.  OE enables reading, WR enables writing.  Could that have something to do with this?
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 03, 2018, 07:26:40 pm
Do you happen to have some address lines floating in the new bigger device?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 07:29:55 pm
I am addressing all of them.  Also, my memory test technique is like this:

Pass 1 - write 0x55 to entire 512K
Pass 2 - verify each byte is 0x55 and then write it to 0xAA to entire 512K.
Pass 3 - verify each byte is 0xAA and then write it to 0x55 to entire 512K.
Pass 4 - verify each byte is 0x55 and then write it to 0xAA to entire 512K.
Pass 5 - verify each byte is 0xAA and then write it to 0x00 to entire 512K.

What is REALLY ODD is that is always fails on PASS 4 which is the same as pass 2!!!
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 07:32:00 pm
Here is my test code.  The disabled enable_sram/disable_sram functions were me testing the memory controller enable/disable at different places in the test routine.  That makes on difference.  There functions to do it with the memory controller and also bitbang which are selected with defines.

Code: [Select]
#include <avr/io.h>
#include "util\atomic.h"
#include "avr/pgmspace.h"
#include "avr/wdt.h"

#include "stdio.h"

#include "cdelay.h"
#include "ddrpin.h"

#define F_CPU 14745600

#define UART_RXBUFFERSIZE  64
#define UART_TXBUFFERSIZE  64

#define A15_PORT      PORTC
#define A15_PIN       7

#define BANK_PORT     PORTF

#define MREQ_PORT     PORTE
#define MREQ_PIN      5

#define LATCH_PORT    PORTE
#define LATCH_PIN     4

#define MEMORY
//#define BITBANG


//____________________________________________________________________________________________________________________________________

volatile unsigned char RxBuffer[UART_RXBUFFERSIZE],RxPtrIn,RxPtrOut,RxItems,TxBuffer[UART_TXBUFFERSIZE],TxPtrIn,TxPtrOut,TxItems;

void uart_putc(unsigned char AChar)
{
  //delay if the buffer is full
  for(;TxItems==UART_TXBUFFERSIZE;)
    ;

  //add char to the buffer
  TxBuffer[TxPtrIn]=AChar;
  TxPtrIn++;
  if (TxPtrIn==UART_TXBUFFERSIZE)
    TxPtrIn=0;
  ATOMIC_BLOCK(ATOMIC_FORCEON)
    {
      TxItems++;
      UCSR0B|=_BV(UDRIE0);
    }
}

void uart_puts(char *AString)
  {
    char c;

    while ((c=*AString++))
      uart_putc(c);
  }

void uart_puts_P(const char *AString)
  {
    char c;

    while ((c=pgm_read_byte(AString++)))
      uart_putc(c);
  }

unsigned char uart_getc()
  {
    unsigned char c1;

    if (!RxItems)
      return 0;

    c1=RxBuffer[RxPtrOut];
    RxPtrOut++;
    if (RxPtrOut==UART_RXBUFFERSIZE)
      RxPtrOut=0;
    ATOMIC_BLOCK(ATOMIC_FORCEON)
      {
        RxItems--;
      }
    return c1;
  }

void uart_clear_rx_buffer()
  {
    ATOMIC_BLOCK(ATOMIC_FORCEON)
      {
        RxPtrIn=0;
        RxPtrOut=0;
        RxItems=0;
      }
  }

void uart_clear_tx_buffer()
  {
    ATOMIC_BLOCK(ATOMIC_FORCEON)
      {
        TxPtrIn=0;
        TxPtrOut=0;
        TxItems=0;
        UCSR0B&=~_BV(UDRIE0);
      }
  }

ISR(USART0_UDRE_vect)
{
  if (!TxItems)
    {
      UCSR0B&=~_BV(UDRIE0);
      return;
    }

  UDR0=TxBuffer[TxPtrOut];
  TxPtrOut++;
  if (TxPtrOut==UART_TXBUFFERSIZE)
    TxPtrOut=0;
   TxItems--;
}

ISR(USART0_RX_vect)
  {
    char c1;

    c1=UDR0;

    if (RxItems==UART_RXBUFFERSIZE)
      return;

    RxBuffer[RxPtrIn]=c1;
    RxPtrIn++;
    if (RxPtrIn==UART_RXBUFFERSIZE)
      RxPtrIn=0;
    RxItems++;
  }

char s1[64];



// memory interface

#ifdef MEMORY

void enable_sram()
  {
    //memory controller
    XMCRB=_BV(XMM0); //we control A15 manually through PC7
    //XMCRA=_BV(SRW11) | _BV(SRW10); //2 wait plus
    //XMCRA=_BV(SRW11);              //2 wait
    //XMCRA=_BV(SRW10);              //1 wait
    //XMCRB|=_BV(XMBK); //bus keep
    MCUCR=_BV(SRE);

    //A15
    DDR(A15_PORT)|=_BV(A15_PIN);

    //BANK0-3
    DDR(BANK_PORT)|=0x0f;

    //MREQ
    DDR(MREQ_PORT)|=_BV(MREQ_PIN);

    //LATCH
    DDR(LATCH_PORT)|=_BV(LATCH_PIN);
  }

void disable_sram()
  {
    //memory controller
    XMCRB=0;
    XMCRA=0;
    MCUCR=0;

    //A15
    DDR(A15_PORT)&=~_BV(A15_PIN);

    //BANK0-3
    DDR(BANK_PORT)&=~0x0f;

    //MREQ
    DDR(MREQ_PORT)&=~_BV(MREQ_PIN);

    //LATCH
    DDR(LATCH_PORT)&=~_BV(LATCH_PIN);
  }

uint8_t getbyte(uint16_t AAddress)
  {
    return *(volatile uint8_t*)AAddress;
  }

void setbyte(uint16_t AAddress, uint8_t AByte)
  {
    *(uint8_t*)AAddress=AByte;
  }

#endif


#ifdef BITBANG

// bit bang

#define RD 1
#define WR 0
#define ALE 2

void enable_sram()
  {
    PORTG|=_BV(WR) | _BV(RD); //RD + WR
    DDRG=_BV(WR) | _BV(RD) | _BV(ALE);
    DDRC=0xff;
    DDRA=0xff;
 
    //A15
    //DDR(A15_PORT)|=_BV(A15_PIN);

    //BANK0-3
    DDR(BANK_PORT)|=0x0f;

    //MREQ
    DDR(MREQ_PORT)|=_BV(MREQ_PIN);

    //LATCH
    DDR(LATCH_PORT)|=_BV(LATCH_PIN);
  }

void disable_sram()
  {
    //memory controller
    DDRG=0;
    PORTG=0;
    DDRC=0;
    DDRA=0;

    //A15
    //DDR(A15_PORT)&=~_BV(A15_PIN);

    //BANK0-3
    DDR(BANK_PORT)&=~0x0f;

    //MREQ
    DDR(MREQ_PORT)&=~_BV(MREQ_PIN);

    //LATCH
    DDR(LATCH_PORT)&=~_BV(LATCH_PIN);
  }

uint8_t getbyte(uint16_t AAddress)
  {
    uint8_t c1;
   
    c1=(AAddress>>8) & 0x7f;
    PORTC=(PORTC & 0x80) | c1;

    PORTA=AAddress & 255;
    PORTG|=_BV(ALE); //ALE
    PORTG&=~_BV(ALE); //ALE

    DDRA=0;

    PORTG&=~_BV(RD); //RD

    asm volatile ("nop");
    asm volatile ("nop");

    c1=PINA;

    PORTG|=_BV(RD); //RD

    DDRA=0xff;

    return c1;
  }

void setbyte(uint16_t AAddress, uint8_t AByte)
  {
    uint8_t c1;

    c1=(AAddress>>8) & 0x7f;
    PORTC=(PORTC & 0x80) | c1;

    PORTA=AAddress & 255;

    PORTG|=_BV(ALE); //ALE
    PORTG&=~_BV(ALE); //ALE

    PORTA=AByte;

    PORTG&=~_BV(WR); //WR
    PORTG|=_BV(WR); //WR
  }

#endif

void A15_high()
  {
    A15_PORT|=_BV(A15_PIN);
  }

void A15_low()
  {
    A15_PORT&=~_BV(A15_PIN);
  }

void setbank(uint8_t ABank)
  {
    BANK_PORT=(BANK_PORT & 0xf0) | ABank;
  }

void dump(uint16_t AAddress, uint16_t ALines)
  {
    uint8_t c1,c2;
    uint16_t ui1;

    for (ui1=AAddress;;)
      {
        sprintf(s1,"%04x: ",ui1);
        uart_puts(s1);

        for (c2=0;c2<16;c2++)
          {
            c1=*(uint8_t*)(ui1+c2);
            sprintf(s1,"%02x ",c1);
            uart_puts(s1);
          }
        uart_puts("\n\r");

        ui1+=16;
        ALines--;
        if (ALines==0)
          break;
      }
  }

const char PROGMEM testsram1[]="Testing 512K Static RAM (pass %d)...";
const char PROGMEM testsram2[]="\n\r";
const char PROGMEM ramfail[]="\n\rRAM FAIL bank %d 0x%04x should be 0x%02x but was 0x%02x\n\rHALTED.\n\r";

void srampass(uint8_t AVerify, uint8_t ASource, uint8_t ADest)
  {
    uint16_t ui1;
    uint8_t c1,c2;

    //enable_sram();

    c2=0;
    for (c2=0;c2<16;c2++)
      {
        if (c2==15)
          A15_high();
        else
          {
            A15_low();
            setbank(c2);
          }

        //enable_sram();

        for(ui1=0x8000;;)
          {
            if (AVerify)
              {
                //c1=*(volatile uint8_t*)ui1;
        //enable_sram();
                c1=getbyte(ui1);
                //c3=getbyte(ui1);
                //c4=getbyte(ui1);
        //disable_sram();
                if (c1!=ASource)
                  {
                    sprintf_P(s1,ramfail,c2,ui1,ASource,c1);
                    uart_puts(s1);

                    //halt
                    for(;;);
                  }
              }
            //*(uint8_t*)ui1=ADest;
        //enable_sram();
            setbyte(ui1,ADest);
        //disable_sram();

            ui1++;
            if (ui1==0)
              break;
          }
        //disable_sram();
      }

    //disable_sram();
  }

uint16_t pass=1;

void testsram()
  {
    //test begin
    sprintf_P(s1,testsram1,pass++);
    uart_puts(s1);

    #define FIRST 0x55
    #define SECOND 0xaa

    enable_sram();

    //pass 1 - set 0x55
    srampass(0,0,FIRST);
    uart_putc('1');

    //pass 2 - verify 0x55, set 0xaa
    srampass(1,FIRST,SECOND);
    uart_putc('2');

    //pass 3 - verify 0xaa, set 0x00
    srampass(1,SECOND,FIRST);
    uart_putc('3');

    //pass 4 - verify 0x55, set 0xaa
    srampass(1,FIRST,SECOND);
    uart_putc('4');

    //pass 5 - verify 0xaa, set 0x00
    srampass(1,SECOND,0);
    uart_putc('5');

    disable_sram();

    //test end
    uart_puts_P(testsram2);
  }

int main(void)
  {
    //disable wdt
    wdt_reset();
    wdt_disable();


    //half speed
//    XDIV=255; //half speed
//    XDIV=253; //quarter speed
 

    //enable interrupts
    sei();

    //enable usart0 at 9600bps
    UBRR0L=95;
    UCSR0B=_BV(RXCIE0) | _BV(RXEN0) | _BV(TXEN0);
    uart_clear_rx_buffer();
    uart_clear_tx_buffer();

    //for(;;);

    //test sram
    for(;;)
    testsram();

    //halt
    for(;;)
      ;
}

Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 03, 2018, 07:35:43 pm
Yes, you are addressing them, but are all address lines wired to the MCU :) Just use the Saleae to check that each and every address line toggles properly.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 07:49:51 pm
This has yielded something.  Right now if I let it run:

Testing 512K Static RAM (pass 1)...12345
Testing 512K Static RAM (pass 2)...12345
Testing 512K Static RAM (pass 3)...12345
Testing 512K Static RAM (pass 4)...12345
Testing 512K Static RAM (pass 5)...12345

It has gotten up to 170+ cycles.

Using Rigol scope to probe.
When probing A18-A8 everything is as expected, signal gets faster and faster.
A7-A0 are latched, but the second I touch any of them with the scope probe, test fails.  If I hold the probe to the output pin on the AHC573 and press reset to restart the test so there is no noise introduced, the test fails.  On any of them A7-A0.  Also on ALE, same problem.  Same thing with a 10K pullup on ALE or 10K pulldown on ALE.  Runs fine until I attach the 10X scope probe, then fails in PASS 4 as always.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 08:03:03 pm
Even if I probe VCC on the 573, it fails.

I had VCC connected to the top rail of a BB and next to it a 100nF cap going to a ground on the top rail.  Top and bottom BB rails connected with two jumpers on each side.  The ground on the IC was just grounded.

I tried adding two more 100nF caps, they didn't change anything.

I then put a cap all the way across VCC and GND over the IC.  This made it worse.  It was failing with no probe on VCC, but working with a probe on VCC!

I then just have a single 100nF cap going from the VCC pin to the top ground, and a 100nF cap going from the GND pin to the bottom VCC.

Now it just fails all together.

All my examples of it on the LA showed the latching to be working fine with the 573.  But I wonder if the switching all at once from FF to 00 creates noise and creates the issue.

Do I need to try some different value caps?  10nF 1uF?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 08:07:38 pm
The thing is that this SRAM is supposed to allow you to keep OE enabled and changing the address should change the output to the right amount.  Even if there was some 573 latch wierdness going on, the value it is outputting is NOT in the SRAM.  The SRAM only has one of two values in it and what it is outputting is NOT one of them.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 03, 2018, 09:25:19 pm
The bread board is not going to help, and sorry If I lead you up the garden path as from your comments I thought you had validated the signals so in my mind that would have left only the code but now I'm not so sure.

Daves done a video about parasitic capacitance on breadboards and could explain some of the weird "I touch any of them with the scope probe" and other wave hand over it magic
https://www.eevblog.com/forum/blog/eevblog-568-solderless-breadboard-capacitance/ (https://www.eevblog.com/forum/blog/eevblog-568-solderless-breadboard-capacitance/)

I would put your Rigol on each of your lines and look at the wave forms - keeping in mind that the scope probe itself has some capacitance. Check that rise & fall times are good for the speed you want to operate at and that the logic level reach those specified and in the datasheet. It gives these as HIGH= 2.2 to Vdd + 0.5V  AND LOW= –0.3 to 0.8V.

Once your happy with that probe two lines at a time (if you have more channels all the better) and check the timing between line transitions. See page 7 onward for the read and write times and diagrams. Look at the times between the transitions and that you meet the required hold times.

And BTW I would totally validate the write cycles first because you have to write before you read, and yes at this point I would be ignoring the fact that your test passes 2nd, 3rd, 4th passes.

Do ALL of the above with your oscilloscope rather then your logic analyzer you need to have eyes on the wave forms.

One more thing, filling the entire address space with different values is a good test if you know that your both writing and reading the entire address space. For testing I would write the first 8 bits of the address to itself, that way you have some changing pattern and can test it increments properly when you read back.



Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 09:59:13 pm
No worries David; I have been on the garden path for awhile all on my own.  I appreciate the help.  I put a 1uF and 10nF on the VCC and it helps.  I think I made it almost 200 passes no error and I could probe many pins but not all of them without errors.

What I don't understand though is that even if I slow things down to 1/2 or 1/4 speed, I was still getting the error.  Also why always in pass 4, that just doesn't make any sense.

Previously when I read the data, I would get the right value if I read it twice.

I know the full single pass approach I'm using is probably not ideal.  Probably a non repeating PRNG that sets each byte to its own value and then testing that, and then perhaps the same process repeated a 2nd time except that it is inverted from the first time to flip all the bits.

Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 10:03:36 pm
14.7456 MHz = many passes >100
7.3728 MHz = fails immediately
3.6864 MHz = fails immediately
1.8432 MHz = fails immediately

Always in pass 4, even though pass 2 is identical.  If I add passes 5/6 it still fails in 4.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 03, 2018, 10:32:27 pm
supply rail bypassing is law.

Just interested if your bitbang version works at those different speeds? I was looking at your source code and notice. You set XDIV to modify the peripheral clock speed? The bitbang version of getbyte() just has a couple of NOP's so how fast does that run? Can you make it run at the different speeds you mention to compare?

If you have a little inductance in the mix then you may have some resonance? Your signals could be getting attenuated at the lower frequencies. Put your scope probe on the fastest clocking line and check it at those different frequencies. (edit: probably just wild speculation)

OR another thought is that, seeing as you have identified an issue with the VCC rail, the slower speed is causing a line to be high or low longer and hence pulling more power out of the pins? Actually now I think of that is there any change you have at any time OE low on your SRAM and your DATA BUS still set to output? You would then could be sinking 100% in to your MCU. That could be one way to explain he 'first run fail' if the port direction is not correct on the first pass.

[edit] you could see the power dropping put a 100 ohm 10 ohm resistor in series with vcc and probe vcc at the SRAM with your scope you may be able to see when what data line is triggering the dropout. ?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 03, 2018, 10:46:44 pm
Bitbang works at full speed and my test at half speed.  Even so it is considerably slower.

The memory interface controls when the ADx pins are input or output directly.

I wasn't seeing the power dropping, just noise on it increasing.  Before I had the 1uF on it, if I watched it with the scope, I could see a lesser level of noise and then the noise increases maybe 200% right as it fails.  The breadboard is only using 30mA or so, I've got 2 VCC jumpers and 2 GND jumpers powering it with a couple of electrolytic alum caps on the top power rail.

Now it is failing in pass 6!  It is always the same, bits end up higher than they should be.  0xAA ends up being 0xFF.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 03, 2018, 11:16:58 pm
0xFF reads could mean the bus is in high-z state? but if the SRAM is in brownout then who knows what it's doing.

I would still recommend putting a 10 to 100 ohm resistor in series with VCC, the aim is to exaggerate the fault condition / make it fail in a reliable and controlled way. Once you can make it fail probe around and find out where in your code the fault condition is being triggered. I realize that's easier said then done.

You still have a schrodinger's circuit here :)
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 12:56:10 am
It has two VCC's and two GND's.  Should I put a resistor on each one?

Bitbanging has run 353 times for 7 passes each no errors.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 01:25:04 am
I'm going to abandon the AVR external memory interface.  I saw someone else complaining about trouble after some searching.  I'm going to bit bang it, but optimize it to be as fast as it can be.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 04, 2018, 01:25:16 am
It has two VCC's and two GND's.  Should I put a resistor on each one?

Bitbanging has run 353 times for 7 passes each no errors.
Just one resistor should do.

Did you mean bitbang has only passed 7 out of 353 runs?

Sent from my SM-G950F using Tapatalk

Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 01:35:20 am
353 runs * 7 tests = 2471 successful passes.

There _has_ to be something weird going on with the way the external memory interface works.  I can't see what it is but it has to be some address is not being driven strong enough or some other oddity.  I can't image why the SRAM would output 0xFF when that is not what is stored there, but yet there it is.  Could that happen when an address line isn't being driven hard with 0 or 1, I'm not sure.  I know A0-A7 are being driven with the latch strongly.  I'm not sure about A8-A15 though they looked fine.  Then again, trouble seemed to surround the latch.  It is the one that the datasheet recommends.  Maybe they never tested it with 10-12ns SRAM, but slower 45/55ns SRAM.  It could be that their interface was never tested with faster SRAM I suppose.  Someone in 2004 said they had trouble with it.
Title: Re: Signal problem with SRAM...
Post by: David Chamberlain on March 04, 2018, 02:43:59 am
353 runs * 7 tests = 2471 successful passes.

There _has_ to be something weird going on with the way the external memory interface works.  I can't see what it is but it has to be some address is not being driven strong enough or some other oddity.  I can't image why the SRAM would output 0xFF when that is not what is stored there, but yet there it is.  Could that happen when an address line isn't being driven hard with 0 or 1, I'm not sure.  I know A0-A7 are being driven with the latch strongly.  I'm not sure about A8-A15 though they looked fine.  Then again, trouble seemed to surround the latch.  It is the one that the datasheet recommends.  Maybe they never tested it with 10-12ns SRAM, but slower 45/55ns SRAM.  It could be that their interface was never tested with faster SRAM I suppose.  Someone in 2004 said they had trouble with it.
If you watched the video i linked then youll know you are already pushing the limits of a breadboard at those frequencies.

I sugested you look at the waveforms. Rise times, hold times. And so on.

I could keep throwing out ideas but it would be good to see some scope images.


Sent from my SM-G950F using Tapatalk

Title: Re: Signal problem with SRAM...
Post by: texaspyro on March 04, 2018, 04:24:48 am
You are using a VERY poor memory test.  It will not find addressing faults.  Try:

Fill memory the 55 AA AA,  test pattern.
Fill memory with AA 55 AA, test pattern.
Fill memory with AA AA 55, test pattern.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 04:32:11 am
Are you sure - I am not writing all memory with a single value and then trying to read all memory.

I am first filling it with a known value, such as 0x55.

Then I go through it and do 2 things, verify it was 0x55, then write immediate to 0xaa.

If there are any addressing faults that put a 0xaa in the wrong location, it won't be 0x55 when I read it.

Each byte must be the old value and then it get changed to the new value.
Title: Re: Signal problem with SRAM...
Post by: texaspyro on March 04, 2018, 04:45:28 am
Yes, I'm sure...  the 55 AA AA test is the simplest, fastest test that has the best fault finding properties.

Even if you check the full memory after every AA write, there are error modes that might not be detected... and that is an order N*N test time wise.
Title: Re: Signal problem with SRAM...
Post by: bson on March 04, 2018, 01:48:15 pm
Instead of probing the latch, capture the input to the SRAM and see which of its timing requirements is violated.  For example, there is a 6ns delay for the -10 device after you release WE# before the outputs become valid again (tLZWE). During this period you can't start a read.  But, you really should start probing at the SRAM end to investigate what it sees rather than the latch (which I'm sure latches just fine, or writes wouldn't go to the right address).
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 04:31:19 pm
It did 3707 x 7 passes last night with no error using the bit bang method.

bson - I'm going to try the memory controller once more - I'll watch the CE, WE, RD signals with my Saleae to find out if any of the timing requirements are being violated.
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 04:47:33 pm

You might want to put some resistors in the data leads to the memory to catch a fight between outputs.

And to get high speed takes current, make sure you have good bypass close connected to ram chip power pins.

Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 05:36:38 pm
And to get high speed takes current, make sure you have good bypass close connected to ram chip power pins.

I'm starting to get this guys - I think you are all on the right track.

The sram2.jpg shows my capture and you can see clear noise on the CE line that causes the failure.  The CE pin is not being driven by the microcontroller currently, it is grounded into the breadboard ground bar.

The sram2s.png shows the normal amount noise when all is functioning, the sram2b.png shows the noise when it fails.

I do have a 100nF bypass cap in the breadboard under each pair of VCC/GND pins, but perhaps that is not good enough.  See 2more.jpg for a picture of this sram dip adapter.

Do I need to manually put some bypass caps ON the top of the breadboard adapter?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 06:05:45 pm
I added two 100nF caps to the leads on the IC.  Not seeing the CE noise on the LA, but still failing.
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 06:07:29 pm

small, median large a size range
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 06:11:21 pm
Do you mean I need something like 10nF, 100nF, 1uF ?

I've got two 0402 100nF's soldered on it right now.
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 06:16:19 pm
yes
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 06:22:20 pm
Not sure what I have in my parts - should I put something larger or smaller?  On both VCC/GND pins?

The CE pin produces a ton of noise!  If I switch to the lower voltage threshold in the Saleae 1.8v instead of 3.3v, it shows up.  The Rigol shows about 2V (+1V to -1V) in noise.

You would think the datasheet would mention bypassing in some detail if it is so sensitive.
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 06:53:54 pm

Think you have ram floating on wires.
Wires have inductance and prevent fast current changes.

If you look at data sheet, sleep mode very little power with big change to active.

That is a TTL logic part.
0 to 0.8v is active with greater transition to sleep for CS.

For jumpers to low logic, use low value resistors. If you have ringing then resistance will eat the ringing.
For pins you can, pull them high with a resistance. Can use a higher value here.
OR
Connect them to other drivers.
A16-A18 could be connected to A13-A15


Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 07:13:39 pm
Connect them to other drivers.
A16-A18 could be connected to A13-A15

I am not understanding what you mean.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 07:29:05 pm
I still don't understand how I can bit bang it and it works perfectly, but if I try to run it through their memory interface, it does not work.  I can also slow down their memory interface by slowing the clock, but it does not help.  Shouldn't both have signal issues?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 07:42:07 pm
I put the RD and WR signals through a 470 ohm resistor, but no change.
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 04, 2018, 07:44:00 pm
I still don't understand how I can bit bang it and it works perfectly, but if I try to run it through their memory interface, it does not work.  I can also slow down their memory interface by slowing the clock, but it does not help.  Shouldn't both have signal issues?
If the pins configured as GPIO pins has weaker drive capability ie. slower rise and fall times compared to the situation the device uses the pins as memory interface. The slower rise and fall times may reduce any signal integrity issues and potential crosstalk. Bit banging may also reduce a number of simultaneously changing signals which will ease any problems with the power supply bypass or ground bounce etc.

The /WR, /RD and /CE signals are most critical signals. You wrote earlier that you have grounded the /CE signal. That means that it the /WR should have any glitch what so ever, some memory contents will be corrupted depending of the address bus state.
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 07:49:20 pm
A16-A18 are extra address inputs when you have a 16 bit address.

You could strap to a level. With TTL it's best if you can to use a pull-up resistor. With the correct value a logic low can still pull pin low due to difference in what is a low and what is a high. Low is higher current then high.

With an address input connected to a second address input what happens is that data is just stored in different location.

This ram chip looks to be fully random so you can use a random address input connection. The real address to random address is still one to one so what goes in is what comes out.

The old dymanic rams were based on rows & col. and the properties were different.
Rows handled the refresh of data.  The Col data could be fast read or write.
In this case you have two groups of addresses that need to each follow the rules.

So with a static ram that acts like one big storage you can connect any real address line to any address pin on ram an everything is fine.

A driver is normally better then a pull up resistor. 

First put a lot of capacitance close to ram chip to counter the wires.  Bulk with many stages of bypass to reduce the noise.

Keep in mind that bit bang is slow and can allow noise to settle.

The AVR lets you slow access but has no controls for change over speed.
I would look at the time when AVR is driving the data bus to the time the ram is driving the data bus.
The ram due to it's speed could be trying to drive before the AVR is ready.
This is why I suggested some series resistors in ram data lines.
You want a value as small as possible that lets one output to be low with other output high yet has little effect when you have output to input.


Title: Re: Signal problem with SRAM...
Post by: alank2 on March 04, 2018, 09:29:06 pm
Does the faster SRAM just have higher/tighter requirements, even is used slower?  I was running a 55ns 128K SRAM before without trouble.  Should I be looking at a 45ns-55ns piece of SRAM instead?  I plan on using this with a Z80 as well.  Maybe it would all work on a real PCB, but maybe it wouldn't...
Title: Re: Signal problem with SRAM...
Post by: C on March 04, 2018, 10:29:27 pm

an easy way to think is that to go faster you use energy quicker.

Some times looking at extremes lets you get a better picture.

If you want to change the charge on a huge cap, you use more voltage difference and more current to change faster.

The data sheet for your ram lists  5p input and 7p output.
Same deal goes, fast means energy quicker which puts higher demands on supply.
Keep in mind that change takes power.

The high speed ram you have is equal of old time cache ram.

The faster the ram the higher the Z80 clock can be with out wait states.
Fast means that you have to be careful with signals. If you put signals on a ribbon cable, fast leads to cross talk. Last gen ATA hard-drive cables added a ground wire between signals to get speed. This is good up to a point when you need to go differential signals. To go still faster it's probably a differential current for signals.

To get faster you have to tighten the specs.
For your ram you have how long it takes to read/write the data, but you also have how fast you can do the next cycle or read/write. Both effect total max memory speed.

When driving a signal you can get ringing. A small series resistor can help.
With a bus you often find a termination resistor network at both ends. And in some cases an active termination.

So unless you find a speed control, faster always tries to work at max speed.
So faster has signals that change faster with smaller times and hits power pins harder for a shorter time.
All can be handled with care.

For example you will have better luck using ribbon cables to connect to ram or a great bus on pcb.

With this ram having cache mode an address change starts an access cycle.
Valid data is when all the times match requirements.

So step one is put some bulk power storage & bypass as close to ram power pins as possible.

Step two is clean up your wire connections.

Need to think of big picture of when Z80 & AVR is connected to ram. Z80 has DMA mode to allow other control, Does AVR have this?
Note that Z80 could use many clock cycles before DMA change starts.
If this is to long a wait then an option might be double speed ram connected to a dual port switch or paying big bucks for a dual port memory chip.

Keep in mind that using ram for mmu you will have a min of two rams in series.



Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 12:17:51 am
The AVR can get on/get off the address/data bus just like the Z80.

When do lines on a PCB need to be given more treatment such as worrying about their length and terminating them?

I added a 3 uF cerarmic to one side of the vcc/gnf and a 10 uF alum to the other side.  Same failure.

Could the noise be generated ON the CE pin?  If I probe the ground it is plugged into, there is less noise.  When I probe a lead connected to the CE pin, there is more noise.

Do you think on a proper pcb with ground plane that this would happen?

1/8th speed fails.
Title: Re: Signal problem with SRAM...
Post by: C on March 05, 2018, 12:55:51 am

The low level for TTL is c to 0.8v.
Noise on ground can be a big problem.

Would suggest making direct connections between AVR, ale latch and ram for ground. Think many wires so ground is a very solid connection. Use as short of wires as possible.
Need to remember that return path for single ended signals is via the power bus.

On a PCB it is a good idea to try to keep faster signals the same length if you can. It is also good not to have branches to these signals.
The longer the wire length & faster the more you need to terminate at ends of wire.

An example of extreme was last gen parallel SCSI bus. Just difference in the actual wire made signals arrive at different times so a big part of interface was shorting the mess out.

How is the CE lead connected?
I was thinking you had it connected with logic or a very low resistance to ram ground pin.

You might try reading same location many times to see if there is a change.

Have you checked the times?
How much time exists between AVR not driving the data lines until Ram starts driving them?

How much time exists between ram driving data lines on read until AVR starts driving them?


 
Title: Re: Signal problem with SRAM...
Post by: hs3 on March 05, 2018, 01:23:24 am
Does the faster SRAM just have higher/tighter requirements, even is used slower?
What are the rise and fall times like? Any difference between the faster and slower SRAM? Seems like you have the capability to measure these.

How about setup and hold times? Any difference between the faster and slower SRAM? Datasheet should tell you these values.

Have you done timing analysis of the interface based on the setup and hold times of the microcontroller SRAM interface and SRAM?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 03:37:21 am
I put both the AVR and SRAM on the same breadboad.  I couldn't fit my MMU (74ahc32) or the latch (74ahc573), but they got put on a breadboard underneath it and they are only using the power rail on the bottom of the top breadboard.  I used all bent wire jumpers.  I have CE grounded and the OE on the latch grounded.  I have not done much testing yet, but it will last 4 or 5 passes before failing now which is a strong improvement.  If I connect up the RD/WR lines also to the saleae pro 16, it seems to dampen the lines a bit to make it last considerably longer such as 44 passes before failure.

I'll try to do some testing/measuring on it tomorrow as far as rise times/fall times.  I'll put a pull up or pull down on some of the data lines to see when they go high or go low to know when they are being driven/not driven.
Title: Re: Signal problem with SRAM...
Post by: texaspyro on March 05, 2018, 04:24:33 am
Try placing a damping resistor in series with each of the lines that are driving the SRAM.  Place the resistor at the driving chip.  (say around 50 ohms, or even better scope one of the pins at the memory chip and try various resistors so see which one produces the best looking waveform at the memory chip)

You might want to start with just the address lines and test,  next add the control signals,  finally add the data lines.
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 05, 2018, 08:03:48 am
I would suggest placing the 50 ohm termination resistor to the control signals first as they are the most critical signals. Add other resistors if needed. Place the 50 ohm resistors as close to the MCU as possible because you are trying to build series terminated transmission line. 50 ohm is the first guess. You can use the oscilloscope to measure how well the termination works. Make the measurement at the SRAM pins, and tweak the resistor value up if you see excessive overshoot or ringing.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 03:10:22 pm
I tried 47 and 220 on the RD/WR lines.  They have some overshoot and ring, but they cross the 0.8V threshold cleanly enough.  It would run for 4 or 5 passes before failing.  The 220 was definitely squashing the square wave a bit.

The Dx lines go to the SRAM and then on to the latch.  I tried modifying just D0 by putting the 220 in series, it failed quickly and when it did the final bit was still high when it shouldn't be.

Is this hardship of signal integrity because the part is so fast?  10ns is 100 MHz.  Should I try a 45ns/55ns part?  I will try a few different resistor values on the data lines next.  When I probed them they do seem to have quite a bit of noise and the signals are not anything like the RD/WR.
Title: Re: Signal problem with SRAM...
Post by: C on March 05, 2018, 03:23:28 pm

Think about logic speed.
There is two parts

How fast the change from one logic level to other.

How long the delay from input to output.

When you are talking about ram access speed, you are talking the second.

Grab the data sheets for a bunch of different speed ram chips and look at the changes.

You could have a 100ns ram with fast input/output changes.

Logic always tries to work at max speed. The load on the outputs can slow the changes from max speed.

So what is the differences other then access speed?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 05:23:39 pm
Should I consider trying to drive it with a TTL based 573?  If so, what series?
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 05, 2018, 06:52:05 pm
Have you measured the possible ground bounce you may have in the circuit (hook the oscilloscope GND to MCU GND and measure the SRAM GND). Do you see that SRAM GND is jumping when you are running the test, or is the GND reasonable quiet?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 07:13:16 pm
The noise is both positive/negative with respect to ground.  300-400mV, p-p twice that.  The noise does increase in that final pass - I think now know why.  Most passes move between 0x55 or 0xAA, but the final pass goes from 0xaa to 0x00.  This seems to increase the ground noise over going from 0xaa to 0x55, or 0x55 to 0xaa.
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 05, 2018, 07:17:50 pm
It seems that you have a ground bounce problem. The return current from the address, data and control lines are too fast or high to your ground wire inductance and/or resistance. So, you need to improve the ground impedance of your circuit.

Edit: improve = reduce.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 05, 2018, 07:26:35 pm
I did put the AVR and SRAM on the same breadboard to help with this.  Both have short GND connections to both the top and bottom rail.  What else can be done?
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 05, 2018, 07:40:14 pm
Breadboard is not a good thing for circuits with fast signal transitions. Here is one video on how to do it on a breadboard if you *really* want to use the breadboard although you may still run into problems:

https://hackaday.com/2015/10/13/triple-frequency-vfo-on-a-bamboo-breadboard/

Notice how he has used a copper clad board as the ground plane for his project, and he has connected the grounds with very short wires into the copper ground plane. If you want to do it properly, just dump the breadboard and glue the boards on top of a copper clad board and use that as a ground plane, and solder the wires from point to point in your circuit. You can do it dead bug style (place the boards upside down) if it helps with wiring, soldering and probing. High speed electronics is not the easiest thing to do, but it is doable even using simple breadboarding techniques, proper ground plane and good wiring practices.

Here is a nice video on breadboard problems at higher frequencies:

https://hackaday.com/2016/01/19/solderless-breadboard-parasitics/
Title: Re: Signal problem with SRAM...
Post by: GeorgeOfTheJungle on March 05, 2018, 08:47:24 pm
In the video... he's left inputs floating?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 12:52:55 am
I tried to tie all the grounds together with 3" wires to a single breadboard power rail all next to each other.  This did reduce the noise to about half, but did not solve the problem.  I'm guessing there is probably ringing going on with the address/data/control lines as well, but with the breadboard it is would be very difficult to put resistors in all the lines to find out.  I would love to know if everything was on a pcb if it would work or have the same problem, but not enough to want to lay out one and order it to find out.  I think I'm going to just go back to 55ns SRAM and see if that solves everything and is less touchy.

Is this where I/O pins with slew rate limiting might have helped me?

I reworked the entire breadboard with the 55ns DIP memory I had (128K) and it is working beautifully.  It can read or write to the SRAM in 4 AVR clock cycles.  Up to 915x7 passes with no errors.  I've got a 512K 55ns SRAM coming tomorrow I can drop right in and test.  The DIP SRAM is only 32 pins and leaves me room to put the latch on the same single breadboard.  Also being DIP it allows me to easily get the scope/LA hooked up to see what is going on.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 01:29:52 am
Looking at some signals shows:

RD/WR rise/fall 3.8ns
ALE rise/fall 3.4ns
74ahc573 latch output rise/fall around 4.5ns
73ahc32 rise 5ns/fall 7ns

It stays running rock solid even if I probe pins with the scope probe.

Edit - I move the AVR up to 20 MHz for 50ns pulses on RD/WR/ALE and it is still working perfectly.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 06, 2018, 03:24:47 am
You may want to set the wait state since it works fine bit banging. I'm using an overclocked AVR with external 10ns SRAM controlled by the xmem interface, no wait states, and it works fine but it's on a proper PCB. I have interrupts running about 500khz and still no errors. Definitely an issue with your wiring/breadboarding.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 03:31:58 am
Bit banging worked without the latch, but failed with the latch.  I do wonder if a proper PCB would do wonders for it.  Which AVR are you using?
Title: Re: Signal problem with SRAM...
Post by: hs3 on March 06, 2018, 11:24:21 am
Is this where I/O pins with slew rate limiting might have helped me?
Earlier when you were asking about the possible differences between faster and slower SRAM and I suggested checking the rise and fall times and if there was any difference I was thinking mostly about checking the slew rates of the SRAM output drivers. It wouldn't be surprising that faster RAM would have faster output driver.

I'm not sure if you have checked the SRAM output slew rates in your circuit?

If you think about wide RAM with multiple strong output drivers switching at the same time then a breadboard is not usually the best environment for that.

Have you figured out the timing of your RAM interface and how much time is there for the signals to settle after the RAM outputs have switched and before the MCU reads the bus?

You mentioned earlier that the faster SRAM is IS61C5128AL-10TLI. Did you mention the part number of the slower SRAM that didn't have problems? Maybe you did but I missed that.

When measuring things with a scope it might make sense to attach the actual scope screenshots of the measurements here. It could help visualizing things for readers. And sometimes a picture can tell a lot more than a few words. Also I think it could be useful to take a photo of your probing setup. Should help understanding the whole situation in readers minds better too and reduce unknowns.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 01:03:27 pm
The SRAM that is working is AS6C1008-55PCN.  I plan to try AS6C4008-55PCN today when it arrives as well.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 06, 2018, 09:56:06 pm
I'm using a mega2560au16 @20mhz. Is your latch fast enough? What is the p/n? Coincidentally my project will also interface with a z80, although it's largely replacing some addons with a single unique operating mode. I would recommend getting a proper pcb for this, even to play around. There is alot of extra capacitance, resistance and inductance using lots of wires, smt adaptors, and a breadboard. You can get boards cheap enough and you are never left wondering. The xmem interface is fairly quick considering the mcu. I'm actually a little surprised you have no issues with the slower sram and no wait state but if it works, it works.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 10:07:18 pm
The 512K x 8 SRAM (55ns) came in today and it works beautifully.  I'm using a 74AHC573 latch as recommended in the datasheet.  It runs zero wait state no problem - 4 clock cycles for a read or write.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 06, 2018, 10:17:27 pm
Great to hear. What are you using all that sram for?
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 06, 2018, 10:23:51 pm
I'm going to build a CP/M 2.2/3.1 single board computer with the AVR taking over most of the I/O functions, at least that is the idea.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 07, 2018, 08:53:43 am
The entire bios or just I/O? You'll probably end up the same route as me writing a bunch of interrupts in asm. The 4 cycle mem access and 5 cycle min. Entrance time really makes cycles count. My other idea was level shifters and an xmos chip since I know those better than AVR which would also cut out cpld requirement to generate the interrupts but I suppose you'll have another mcu anyhow. Good luck with your project, at least the hardware seems to be working for now.  :-+
Title: Re: Signal problem with SRAM...
Post by: Kalvin on March 07, 2018, 10:55:52 am
The 512K x 8 SRAM (55ns) came in today and it works beautifully.  I'm using a 74AHC573 latch as recommended in the datasheet.  It runs zero wait state no problem - 4 clock cycles for a read or write.
Excellent!
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 07, 2018, 01:12:43 pm
Thanks Kalvin.

maginnovision - I plan to make a DMA buffer that the Z80 and AVR use to communicate with each other.  I'm going to trap an out instruction to trigger a flipflop that assers BUSRQ and then the AVR will do DMA once it has control of the bus.  The Z80 will write a command it wants executed like read a disk record at 0xFFE0 and then trigger the AVR to do it by using "out 0xf0,0".  The AVR will read the memory, perform the operation, write a result code, and then release the bus for the Z80 to check the result code, etc.  So there will be BIOS still to setup the command, but as much as I can ship to the AVR, I plan to try to.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 07, 2018, 04:58:59 pm
Little off topic I use SN74AHC125 for spi level shifting.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 07, 2018, 05:11:31 pm
Little off topic I use SN74AHC125 for spi level shifting.

Which direction?  I've got another thread going asking about this.

I was thinking of using 74LVC125 powered by 3.3V in the AVR->SDcard direction because it has 5V tolerant inputs.

And then a single SN74AHCT1G125DBVR powered by 5V for the MISO coming back into the AVR from the 3.3V device.  It is a TTL compatible part that should go high at 2V and should convert the 3.3V up to 5V, I think...
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 07, 2018, 05:50:58 pm
I use it for miso, mosi, cs, and clk. Since the avr works with 3.3v signals even at 5.0v it works fine. I know you said you have an RTC and perhaps you could just use a resistor for cs line since it's not critical? Alternatively use a part with more than 4 connections. The important thing for me was also to protect for programming so some lines require cs to be low and that has a pullup. I have seen your post at avrfreaks I've just never made an account there.

Title: Re: Signal problem with SRAM...
Post by: C on March 07, 2018, 06:48:34 pm

Before you move on to something else, I think you should really study and learn from this ram connection.

Faster normally takes more power over a shorter period of time.

Look at the difference the data sheets for the two ram chips for differences.

You have difference in power for ram.
You have difference in speed the data lines are driven during read.
You have difference in response times.

The remaining circuit changes little. There might be a small difference in the inputs to ram chips.

Put on your logical thinking cap on and use data sheets and scope and gain some knowledge that you can use in the future.

Think of the current paths.
The negative power input for ram supplies the current for a logic low with the AVR positive power input completing the path.
This reverses for a logic high and is normally lower current for TTL.

If you think it through a cap from AVR Positive to Ram negative could help ground bounce of ram chip.

You can use heaver gage wire for power. The ram negative has to supply ram power & logic low output power.

The other difference is TIME and you really need to use the data sheets for this. You should know the times for ______.

Test, look & modify to learn and save time in the future.

Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 09, 2018, 09:53:10 am
I thought I'd add as I've just had a chance to check. The main difference I can see between yours and mine is I'm using an AHCT latch not an AHC. I know you said you tried an HCT latch and those have the voltage levels you'd want but they are very slow, so that could also be a problem. Any chance you could try an AHCT latch with the faster SRAM?

Quick Edit: This isn't to say you don't have issues with power due to breadboarding/decoupling but if you had one on hand I'd like to see if there was any difference.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 09, 2018, 02:08:36 pm
Before you move on to something else, I think you should really study and learn from this ram connection.

I don't disagree.  I did have the 10ns SRAM working on bit banging only without the latch.  I could never get it to work with the latch, either bit bang or AVR external memory interface.

I thought I'd add as I've just had a chance to check. The main difference I can see between yours and mine is I'm using an AHCT latch not an AHC. I know you said you tried an HCT latch and those have the voltage levels you'd want but they are very slow, so that could also be a problem. Any chance you could try an AHCT latch with the faster SRAM?

Quick Edit: This isn't to say you don't have issues with power due to breadboarding/decoupling but if you had one on hand I'd like to see if there was any difference.

I started with the HCT latch, and then moved to an AHC latch which should be fast enough, but not TTL compatible.  Is the TTL part only for inputs, or does it have anything to do with outputs?  The inputs are all AVR, the SRAM says it is TTL compatible.

I've cleaned up the 10ns dip adapter I had by adding the proper bypass caps.  I've got some 0402 100nF and 1uF on both power inputs.  Someday I'll play with it again, but it has cost me time and I'm not so excited about building up another board with it.  I'd almost rather lay out a cheap pcb and order it to see how it would do on a real board.
Title: Re: Signal problem with SRAM...
Post by: C on March 09, 2018, 03:47:13 pm

You need to really use the data sheets as these contain the facts you need.

For logic
Each output has certain specifications that must be followed.
Each input has certain specifications that must be followed.

The data sheet lists these.

Each logic family has it's specifications that are a little different.
A logic input has three states, Low, unknown, high.
The unknown is range between what is a valid low & a valid high

A logic output when valid leaves some margin in voltages for noise, wire resistance and other.

Look at data sheet
DC ELECTRICAL CHARACTERISTICS
Voh Output HIGH Voltage
Vol Output LOW Voltage   
Vih Input HIGH Voltage
Vil Input LOW Voltage

From you post you are not reading or checking these.

If you were then you would know if an output can be connected to an input.

When designing in logic
1. you have to get logic correct.
2. you have to get DC & AC connections correct.
3. you have to get the time delays correct( every thing has a time delay)
4. you have to get the power correct.

You can not just work at a high level, the low level stuff must function properly.

So you should know what a pin on your AVR can do & limits for total chip. A logic low is ____ ,a logic high is __ for output & ____ for input

This is true for all the chips. Break the rules and you get random mess.
Each chip has rules, the family has rules, logic has rules.

You can waste a lot of time by not looking and using the details.

What good is building a PCB if you do not know what changes it will make?
There are a lot of fails just due to poor PCB's.

If you re-test your ram circuit and only change just the ram chip, what has changed?
Make a list
Does input's to ram change?
Does output's from ram change?
Does power change?
How does timing change?

What will these changes have on rest of circuit?

Can a pin on AVR be an output at same time as connected to a output from ram?  A two output fight can lead to very high currents with any overlap.

Look at the current paths. That ground connection for a chip has to carry a lot of current at times.
Do simple math.
Ram has 8 outputs
The ground connection for ram has to carry the power to ram chip, the power to the outputs, the power to the inputs.
So a wire the same size and length for ground as other connections will have a times huge voltage drips compared to other wires. Just the outputs can make 8x current change difference.

With out looking I will guess that the faster ram chip was making huge changes in ground levels, commonly called ground bounce.
The way you remove this is bigger conductors.
Cross coupling of power pins. In addition to cap's across power pins of chip, you have cap's from power on one chip to power on other.  A cap network connected between AVR + & Ram - with second the other way.

So save your self some time and get the basics correct.

Think about why bit banging worked and other not.
Difference is Time. Time changes and noise of power rails change which effects logic levels. With more time power rails get better and outputs become better.

 

Title: Re: Signal problem with SRAM...
Post by: alank2 on March 09, 2018, 04:12:57 pm
The software bit bang worked because the latch was missing, it failed with the latch present.  Something about that latch was the problem with the 10ns SRAM.  I did have a ground noise issue, but I reduced it significantly by connecting all the grounds together, and the problem still happened.  This makes me wonder if it was more than one issue going on.

I do read the datasheets and was pouring through the SRAM one trying to understand why it was doing what it was doing.  Part of the problem is that with the breadboard, it is tough to hookup any tools to see what is going on as well.  I appreciate the idea about the low/high voltages and requirements.  To me, one stupid thing here, and I probably just don't understand, is why make a CMOS SRAM compatible with TTL voltage levels at all?  All that seems to do is make it more sensitive to voltage ranges you wouldn't think you would want it to be sensitive to.

I'll bet it would work fine on a proper PCB.

My question above was, does a TTL compatible IC like AHCT have any difference in the output compared to a non T part?  I know this input is sensitive to TTL levels.
Title: Re: Signal problem with SRAM...
Post by: maginnovision on March 09, 2018, 05:00:46 pm
The TTL stuff defines high as 2.0 min and low as max 0.8. You can see from the non A parts that it requires a percentage of the supply voltage. So at 5v you'd need almost 4v. The slow non T latch has a rise time of 500ns. When you look at the latches in their entirety the differences can add up. That's going to be more true with power/ground issues for the non TTL latch.

I didn't figure you would want to do the test I just thought I'd ask. Breadboarding that kind of stuff is troublesome and you've already spent a bunch of time on it.
Title: Re: Signal problem with SRAM...
Post by: C on March 09, 2018, 05:18:54 pm
If you look a logic, you should see that levels change.

A valid low for CMOS may not be in range of valid TTL low.

You need to look closer at TTL compared to CMOS

For CMOS you normally have two matched transistors with one pulling low and other pulling high currents are about same.

For TTL the transistors are not matched. More current for a low then for a high. Need to remember that the actual transistors have to be different. A PNP transistor is different from a NPN transistor. To make a match, many changes are needed. Same is true for CMOS.
So by building logic around best NPN and PNP you end up with different currents and voltage levels.

If actual transistors matched then for TTL the lower transistors would be larger and handle more current. Working with the differences you get TTL.

In the past cmos was the slower logic and even today you have to work with the very high currents needed to change a input, the charge/discharge of gate cap. Smaller helps a lot here.


So
From what you state.
Your bit bang was wrong for latch.
Would guess that you got time wrong if you had logic correct.

What is so hard for address it's?
Output 8 bits
Wait
Latch the 8 bits & hold
wait
Output 8 bits
wait
set ram signals
wait

The question is just how long the waits with faster being smaller total waits. Some get removed at fast due to AVR being slow.

So what stops you from trying above very very slow? You can always speed it up in steps.
At some point you will hit a limit.
AVR can not go faster.
AVR program is too fast for very slow ram.

Good tests would let you find more problem areas.
When testing you need to look at detail & total.

For TTL an output of all low is more current then an output of all high. A high is a weak change compared to a low.
Look at all the differences because they interact for total.

When you were trying to bit bang with latch and it failed,
step one is make it slower & check logic.

Get it working and then adj just one thing at a time to find new failure.


So short answer
The T on AHCT does change input levels and can/could change outputs if it makes sense.

Would make sense if lower transistors were larger to better handle larger current.

Read the data sheet for a AHC part & a AHCT part

Need to remember that not all pins of a chip have to be same.
The Z80 clock is different from other pins.
The Z80 outputs can drive TTL but are not true TTL

Need to know difference and limits.


Title: Re: Signal problem with SRAM...
Post by: bson on March 09, 2018, 07:26:29 pm
I am running through a simple 3 pass memory test on the AVR.  If it fails, I get a bank, address, what it should have been and what it was read as.  It does a pass 1 where it writes 0x55 to all 512K, then a pass 2 where it reads it back and verifies it is 0x55 and then writes it to 0xAA, then a final pass 3 where it verifies it is 0xAA and then writes it to 0x00.
This test can't catch many cases where the read address differs from the write address, because you fill the whole chip with the same value.  You need a test where you write, verify, then clear before moving to the next location.  Fill the RAM with 0x00.  Write 0x55, then immediately write 0xaa back-to-back, verify it reads 0xaa, write back 0x00 and move to the next location.  If you have a setup hold or other timing violation that results in a read address or consecutive-write problem this will catch it.  After the testing the whole RAM maybe also verify it's all back to 0x00.
Title: Re: Signal problem with SRAM...
Post by: TerraHertz on March 09, 2018, 11:44:41 pm
Sorry, didn't read all the posts. But I can't find any LA display of your SRAM signals that includes Data, Address, ALE, WR, and OE.
Was also looking for a pic of the breadboard, and found that.
Comments:
* I will bet you are violating setup and hold timing requirements for Address relative to ALE. And maybe data timing relative to WR. Working when bitbanging, but not working when running fast, says that loud and clear.

* Your breadboard method just isn't workable for circuitry with fast transitions. Because the ground return paths are too long and high impedance, the critical signal lines impedance is all over the place, and there's high capacitance between the pin rows inside the plugboard. You're getting ground bounce (effectively causes false logic glitches on any and all lines) plus inter-signal capacitive coupling.
 There has to be adequate cap decoupling at each chip AND solid ground planes AND low inter-signal capacitance.
 There are only two ways to do it right:
 - Proper PCB layout with adequate ground planes and decoupling.
 - Prototyping with matrix board and some grounding method closely equivalent to PCB ground planes. Copper foil, or a dense grid of large gauge ground wires.

The Arduino 'plugin shield' style is OK for slow stuff, but when you have wide A & D buses and fast transitions, it surprises me that with just one (or a small number) of ground pins it ever works at all.

As for memory tests, doing 'all same' AA/55/F0/0F type passes is a very basic test. It does not check for addressing errors. You need to add a phase of writing a pseudo-random sequence to the entire memory, then a read pass that checks that sequence is still all there. Do multiple passes with different starting seeds for the SRNG.
Title: Re: Signal problem with SRAM...
Post by: alank2 on March 11, 2018, 03:35:58 am
Things are starting to come together on it the project a bit.

I injected an "out" command to trigger the BUSREQ via flip flop.  A1 is where the flip flop fires as a result of the OUT instruction.

Z80 response with BUSACK quickly after.

A2 the AVR takes over the memory bus by asserting MREQ.  It writes a HALT instruction to the very next by the Z80 will execute at B1.

B2 releases the BUSREQ and the Z80 continues.  It fetches the HALT and executes it and enters the halt state at C1.