6502.org

The 6502 Microprocessor Resource
http://forum.6502.org/

Problems writing to HM62256 SRAM

http://forum.6502.org/viewtopic.php?t=5584

Page 2 of 2

Re: Problems writing to HM62256 SRAM

Posted: Mon Mar 25, 2019 5:28 am
by GARTHWILSON
Dr Jefyll wrote:
Solater wrote:
Won't the heat damage it?
No, not unless you take a LONG time to do the soldering. A fine tip on the iron is helpful. And you want it to be fairly hot so the job can be done quickly. If you have any extra/worthless IC's around you can practice soldering on them. Edit: I found a photo...
Solater, the chance of damaging the IC with soldering-iron heat is just about zero. In a job I worked in 1984-85, I sometimes used an infrared microscope to thermal scan power transistors' uncovered dice (ie, the actual chips) operating under extreme loads, and I've seen them actually operating (not just in storage or in soldering, but operating) at over 350°C (662°F). I don't know how far over, because I wasn't allowed to get calibration beyond that. Granted, they would not have lasted long, but it did not cause catastrophic failure. 60/40 solder melts at about 180°C.

For various other reasons though, I, too, recommend a hot iron. It was a surprise to our production people when I showed that soldering a plastic switch years ago resulted in less melting and damage if they would use a hotter soldering iron so as to be able to complete the job so quickly there wasn't time for the heat to reach the plastic before everything was cooling again.

Now about the capacitor soldered on the top of the IC: I recommend eliminating the curves and taking the leads diagonally across the top as straight and short as possible, to reduce inductance. It won't be any additional work; in fact, it may be less work. Somewhere I have a couple of pictures I wanted to show of something from my work 25 years ago where we had to scab a multilayer ceramic capacitor on the back of a board, but I can't find them at the moment. Maybe later I'll remember where I filed them. What happened was that when the production people tried to be neat and leave an eighth of an inch of leads between the body of the capacitor and where they bent outward, the circuit didn't always work. I had to stress to them the importance of bending the leads right at the body of the capacitor (but without risking breaking the capacitor inside), to minimize the series inductance. This matter of inductance in our digital circuits with fast rise times can be a real stinker, and gets many hobbyists in trouble.

Re: Problems writing to HM62256 SRAM

Posted: Mon Mar 25, 2019 2:13 pm
by Solater
GARTHWILSON wrote:
Dr Jefyll wrote:
Solater wrote:
Won't the heat damage it?
No, not unless you take a LONG time to do the soldering. A fine tip on the iron is helpful. And you want it to be fairly hot so the job can be done quickly. If you have any extra/worthless IC's around you can practice soldering on them. Edit: I found a photo...
Solater, the chance of damaging the IC with soldering-iron heat is just about zero. In a job I worked in 1984-85, I sometimes used an infrared microscope to thermal scan power transistors' uncovered dice (ie, the actual chips) operating under extreme loads, and I've seen them actually operating (not just in storage or in soldering, but operating) at over 350°C. I don't know how far over, because I wasn't allowed to get calibration data up that high. Granted, they would not have lasted long, but it did not cause catastrophic failure.

For various other reasons though, I, too, recommend a hot iron. It was a surprise to our production people when I showed that soldering a plastic switch years ago resulted in less melting and damage if they would use a hotter soldering iron so as to be able to complete the job so quickly there wasn't time for the heat to reach the plastic before everything was cooling again.

Now about the capacitor soldered on the top of the IC: I recommend eliminating the curves and taking the leads diagonally across the top as straight and short as possible, to reduce inductance. It won't be any additional work; in fact, it may be less work. Somewhere I have a couple of pictures I wanted to show of something from my work 25 years ago where we had to scab a multilayer ceramic capacitor on the back of a board, but I can't find them at the moment. Maybe later I'll remember where I filed them. What happened was that when the production people tried to be neat and leave an eighth of an inch of leads between the body of the capacitor and where they bent outward, the circuit didn't always work. I had to stress to them the importance of bending the leads right at the body of the capacitor (but without risking breaking the capacitor inside), to minimize the series inductance. This matter of inductance in our digital circuits with fast rise times can be a real stinker, and gets many hobbyists in trouble.
Alright, thanks for the anecdote! I won't be so hesitant to solder onto ICs in the future.

Re: Problems writing to HM62256 SRAM

Posted: Mon Mar 25, 2019 2:17 pm
by Solater
DerTrueForce wrote:
If the EEPROM you're talking about is an Atmel/Microchip AT28C256, I've successfully disabled the software write protection before, and written to it in-circuit, but that was using an already-working 65C02 system.
I haven't made much use of that fact yet, but I have done so.

Disabling the software write protection is a matter of writing the correct sequence of writes to the device. The addresses and data required should be in the datasheet.
I've tried to write the sequence specified in the datasheet (https://hardtofind.com.mx/pdfs/textos/A/AT28C256.PDF), but I have been unsuccessful. Do you know if there are timing requirements? As far as I can tell, for the disable algorithm, I can output the data as slow as I want to, and it shouldn't be a problem. Do you know if this is true?

Re: Problems writing to HM62256 SRAM

Posted: Mon Mar 25, 2019 7:52 pm
by Dr Jefyll
GARTHWILSON wrote:
Now about the capacitor soldered on the top of the IC: I recommend eliminating the curves and taking the leads diagonally across the top as straight and short as possible, to reduce inductance.
Yeah, nix the curves. It's not how I usually do the job, but perversely enough that was the only photo I had handy. Today I posted a better one.

Speaking of photos, I wanted to mention to Solater (and remind the rest of you) that on this forum you're welcome to attach images with your posts. This is much preferable to using third-party sites such as Imgur, because of convenience and because of permanency.

Re: Problems writing to HM62256 SRAM

Posted: Mon Mar 25, 2019 10:53 pm
by DerTrueForce
That datasheet you're looking at isn't the same as the one I have, at least in terms of layout. I got mine from the Microchip site.
The write-protection sequences haven't changed, though, so it might not be important.

I think you just have to make sure that you write that sequence, with nothing in between any of them. I have Ittiara run from RAM when I write to it, which does achieve that, but I actually did that because it'll crash the machine if I don't. The write time is much longer than a single cycle(even at 1MHz), and the EEPROM doesn't respond with valid data during that time.

Someone else here has done a similar thing, and he found that operating the AT28C256 too slowly caused some wierd results.

Re: Problems writing to HM62256 SRAM

Posted: Tue Mar 26, 2019 12:42 am
by Solater
DerTrueForce wrote:
That datasheet you're looking at isn't the same as the one I have, at least in terms of layout. I got mine from the Microchip site.
The write-protection sequences haven't changed, though, so it might not be important.

I think you just have to make sure that you write that sequence, with nothing in between any of them. I have Ittiara run from RAM when I write to it, which does achieve that, but I actually did that because it'll crash the machine if I don't. The write time is much longer than a single cycle(even at 1MHz), and the EEPROM doesn't respond with valid data during that time.

Someone else here has done a similar thing, and he found that operating the AT28C256 too slowly caused some wierd results.
I'm back to trying to write to the 28c256. I've added a bypass capacitor across the EEPROM and also implemented the other changes to the circuit Dr. Jekyll suggested. I've tested each of my control, data, and address lines individually, and bit by bit, so I am 99% certain that my output methods are working correctly. However, I still fail to write to the EEPROM and/or disable the SDP.

I didn't see anything in the timing diagram that would indicate this, but do you have to poll whether the data is written while performing the SDP disable algorithm?

Here is my code, for reference:

Code: Select all

#include "Arduino.h"

#define SHIFT_DATA 2
#define SHIFT_CLOCK 3
#define SHIFT_LATCH 4
#define DATA_PIN 5 // first data pin, 7 others will follow afterwards
#define WRITE_ENABLE 13
#define CHIP_ENABLE A0
#define OUTPUT_ENABLE A1

void high_pulse(int pin) {
  digitalWrite(pin, LOW);
  digitalWrite(pin, HIGH);
  digitalWrite(pin, LOW);
}

void low_pulse(int pin) {
  digitalWrite(pin, HIGH);
  digitalWrite(pin, LOW);
  digitalWrite(pin, HIGH);
}

void set_address(int address) {
  shiftOut(SHIFT_DATA, SHIFT_CLOCK, MSBFIRST, address >> 8);
  shiftOut(SHIFT_DATA, SHIFT_CLOCK, MSBFIRST, address);

  high_pulse(SHIFT_LATCH);
}

void data_read_mode() {
  for (int i = DATA_PIN; i <= DATA_PIN + 7; i++) {
    pinMode(i, INPUT);
  }
}

void data_write_mode() {
  for (int i = DATA_PIN; i <= DATA_PIN + 7; i++) {
    pinMode(i, OUTPUT);
  }
}

int read_byte() {
  int number = 0;
  int temp;
  for (int i = 0; i < 8; i++) {
    temp = (int)digitalRead(DATA_PIN + i);
    temp = temp << i;
    number = number | temp;
  }
  return number;
}

int read(int address) {
  data_read_mode();
  set_address(address);
  digitalWrite(WRITE_ENABLE, HIGH);
  digitalWrite(CHIP_ENABLE, LOW);
  digitalWrite(OUTPUT_ENABLE, LOW);
  delayMicroseconds(2); //address to output delay(tACC)

  return read_byte();
}


void write_byte(int address, int byte) {
  set_address(address);
  
  int temp;
  for (int i = 0; i < 8; i++) {
    temp = byte >> i;
    temp = temp & 1;
    digitalWrite(DATA_PIN + i, (bool)temp);
  }
  
  digitalWrite(CHIP_ENABLE, LOW);
  digitalWrite(WRITE_ENABLE, LOW);

  delayMicroseconds(1); //write pulse width(TWP)
  digitalWrite(WRITE_ENABLE, HIGH);
  digitalWrite(CHIP_ENABLE, HIGH);
  delayMicroseconds(1);

}

void write_prepare() {
  data_write_mode();
  digitalWrite(OUTPUT_ENABLE, HIGH);
  digitalWrite(CHIP_ENABLE, HIGH);
  digitalWrite(WRITE_ENABLE, HIGH);
}

void write(int address, int byte) {
  write_prepare();

  write_byte(address, byte);

  digitalWrite(CHIP_ENABLE, LOW);
}

void disable_software_protection() {
  write_prepare();

  write_byte(0x5555, 0xAA);
  write_byte(0x2AAA, 0x55);
  write_byte(0x5555, 0x80);
  write_byte(0x5555, 0xAA);
  write_byte(0x2AAA, 0x55);
  write_byte(0x5555, 0x20);

  delay(15); //wait for write cycle time (tWC)
  digitalWrite(CHIP_ENABLE, LOW);
}

void setup() {
  pinMode(SHIFT_DATA, OUTPUT);
  pinMode(SHIFT_CLOCK, OUTPUT);
  pinMode(SHIFT_LATCH, OUTPUT);
  pinMode(WRITE_ENABLE, OUTPUT);
  pinMode(CHIP_ENABLE, OUTPUT);
  pinMode(OUTPUT_ENABLE, OUTPUT);

  digitalWrite(CHIP_ENABLE, LOW);

  Serial.begin(9600);
  disable_software_protection();
  write(0x4444, 0x55);
}

void loop() {
  Serial.println(read(0x4444));
}

Re: Problems writing to HM62256 SRAM

Posted: Tue Mar 26, 2019 4:21 am
by leepivonka
Remember that the EEPROM control signals CE & OE & Write at all active low.
When you're not running a cycle, the control signals should be inactive (=HIGH).
The general flow of an EEPROM cycle should be
1: Set up the address bus value. Set the data bus direction. Set the data bus value.
2: Toggle the control signals to do the cycle.
3: Return the control signals to inactive.


Here is an untested sample:

Code: Select all

#include "Arduino.h"

#define SHIFT_DATA 2
#define SHIFT_CLOCK 3
#define SHIFT_LATCH 4
#define DATA_PIN 5 // first data pin, 7 others will follow afterwards
#define WRITE_ENABLE 13 // active LOW
#define CHIP_ENABLE A0 // active LOW
#define OUTPUT_ENABLE A1 // active LOW

struct AT28C {

  void Init() { // initialize everything
    pinMode(SHIFT_DATA   , OUTPUT);
    pinMode(SHIFT_CLOCK  , OUTPUT);  digitalWrite(SHIFT_CLOCK  , LOW );
    pinMode(SHIFT_LATCH  , OUTPUT);  digitalWrite(SHIFT_LATCH  , LOW );
    pinMode(WRITE_ENABLE , OUTPUT);  digitalWrite(WRITE_ENABLE , HIGH);
    pinMode(CHIP_ENABLE  , OUTPUT);  digitalWrite(CHIP_ENABLE  , HIGH);
    pinMode(OUTPUT_ENABLE, OUTPUT);  digitalWrite(OUTPUT_ENABLE, HIGH);
    set_data();
    set_address(0x4321);
    }

  void set_data() { // set data bus to be input
    for (byte i = 0; i < 8; i++) {
      pinMode(DATA_PIN+i, INPUT); }
    }

  void set_data(byte val) { // set data bus to be output with val
    for (byte i = 0; i < 8; i++) {
      pinMode(DATA_PIN+i, OUTPUT);
      digitalWrite(DATA_PIN + i, bool((val>>i)&1));
      }

  void set_address(int address) { // set address bus
    shiftOut(SHIFT_DATA, SHIFT_CLOCK, MSBFIRST, address >> 8);
    shiftOut(SHIFT_DATA, SHIFT_CLOCK, MSBFIRST, address);
    digitalWrite(SHIFT_LATCH, HIGH);  digitalWrite(SHIFT_LATCH, LOW);
    }

  byte read(void) { // read a byte, at the same address as before
    digitalWrite(CHIP_ENABLE, LOW);  digitalWrite(OUTPUT_ENABLE, LOW);

    byte number = 0;
    for(byte i=0; i<8; i++) {
      number=(number<<1) | (1&digitalRead(DATA_PIN + i));  }

    digitalWrite(OUTPUT_ENABLE, HIGH);  digitalWrite(CHIP_ENABLE, HIGH);
    return number;
    }

  byte read(int address) { // read a byte
    set_address(address);
    return read();
    }

  void write(int address, byte val) {
    set_address(address);  // setup address bus
    set_data(val);  // setup data bus
  
    digitalWrite(CHIP_ENABLE, LOW);
    digitalWrite(WRITE_ENABLE, LOW);  // do the write
    digitalWrite(WRITE_ENABLE, HIGH);
    digitalWrite(CHIP_ENABLE, HIGH);

    set_data();   // return databus to input
    }

  void wait_for_done() {
    byte v=read();
    do { v^=read(); } while(v&0x40);
    }

  void program(int address, byte val) { // program a byte into the EEPROM
    write(address,val);
    wait_for_done();
    }

  void disable_software_protection() {
    write(0x5555, 0xAA);
    write(0x2AAA, 0x55);
    write(0x5555, 0x80);
    write(0x5555, 0xAA);
    write(0x2AAA, 0x55);
    write(0x5555, 0x20);
    }

  } Ic;

void setup() {
  Ic.Init();
  Serial.begin(9600);
  }

byte val;
void loop() {
  Ic.disable_software_protection();
  Ic.program(0x4444, val);
  Serial.print(Ic.read(0x4443);  Serial.print(' ');  Serial.println(Ic.read(0x4444));
  val++;  delay(500);
  }

Re: Problems writing to HM62256 SRAM

Posted: Wed Mar 27, 2019 12:19 am
by Solater
leepivonka wrote:
Remember that the EEPROM control signals CE & OE & Write at all active low.
When you're not running a cycle, the control signals should be inactive (=HIGH).
The general flow of an EEPROM cycle should be
1: Set up the address bus value. Set the data bus direction. Set the data bus value.
2: Toggle the control signals to do the cycle.
3: Return the control signals to inactive.
Thanks for taking the time to make a sample like this one. After fixing a few typos, I ran your code and it gives the exact same result as mine. No data is written, and only $FF can be read from memory location written to. Interestingly, the code does not halt at your data checking routine, meaning that a bit is changing at some point, assuming it works correctly.

Also, I think the reading routine in your code does not work correctly, as D5 should be the LSB(It is connected to pin D0), although this shouldn't matter in this case.

I must also say that I fail to spot any major differences between your code and mine. Your code is cleaner, but it seems to do the reading and writing in the exact same way. (Except the possible malfunction I just mentoned)

Any ideas what could be wrong here?

Re: Problems writing to HM62256 SRAM

Posted: Thu Mar 28, 2019 4:04 pm
by Solater
As an update, I've received a new 62256 and everything works perfectly. I am still unable to program the at28c256 however.
All times are UTC
Page 2 of 2

Powered by phpBB® Forum Software © phpBB Limited