More I/O pins?

[prlaba]

I need to program some larger ATMEL EEPROMs, specifically the 29C040 512K x 8 EEPROM, a 32-pin DIP with 19 address and 8 data pins. The Nano doesn't have enough I/O pins, and I want to drive the EEPROMs' pins directly, without having to multiplex any pins.

I'm thinking of using a Teensy 4.1, which has more than enough I/O pins and lots of raw horsepower (600 MHz).

Other than having to modify the TommyPROM code to drive the address pins directly (no need to multiplex pins) and change the pin port assignments, is there anything else I'd need to change to get the TommyPROM working with the Teensy? Since the Teensy runs so much faster than the Nano, would I need to "throttle back" the Teensy, or can it just run at full speed?

Thanks.

[TomNisbet]

The current hardware and software design of TommyPROM already supports 19 addresses with a Nano - 16 from the shift register and 3 as direct I/O pins. I've used this to read 29C040 chips successfully.

If you want to use a different Arduino, you will almost certainly need to change the code that writes to the pins. Most of this is in PromDevice.cpp.

Your bigger problem is that the 29C devices are sector-based flash chips. You must write all of the byes for a sector in the same operation. Depending on the manufacturer of your chip this may be a problem. I have seen 29C040 chips with sector sizes of 64, 128, or 256 bytes. The smaller two shouldn't be an issue and may even work with the stock 28C code that TommyPROM uses by default. If not, there may be some small changes needed to the block programming algorithm - I haven't looked at those chips in a while.

If your chip has a 256 byte sector then the problem gets a bit more difficult. The XModem protocol uses a 128 byte block size and the code just does a block write when a new chunk of data is received. This would cause the chip to erase the sector, write the first 128 bytes, and then erase the sector again before writing the second 128 bytes. You would need to modify the code to keep a second buffer and write them both at once as a single block to the chip.

Let me know if you decide to move forward with this. I may be able to offer some guidance if you get stuck.

Tom

[TomNisbet]

You definitely need to leave PKTLEN at 128 because that is defined in the XModem protocol.

It looks like your code is calling writeData with buffersize, which will be 128. Try using sizeof(bufferFull) instead, because that will be 256.

Also, make sure you have defined the block size of the chip to be 256 in TommyPROM.ino, like:
PromDevice28C prom(512 * 1024L, 256, 10, true); // 29C040 with 256 byte sector

[joaopauloap]

in TommyPROM.ino my PromDevice28C was already exactly as you suggested. I had tested putting 256 directly there in the 2nd parameter of writeData and it didn't work, changing to sizeof(bufferFull) neither. My changes in xmodem.cpp are only in the receivePacket function, I didn't change anything in receiveFile, I don't know if I need to change something there.

[TomNisbet]

Can you post your whole ReceivePacket function? It seems correct as you are describing it, but maybe I'll see something in there.

It might also be useful to do a simple test just to make sure that the chip really is able to do a write of a 256 byte sector. Maybe take an existing command, like the zap command. Comment out the existing code and do something like fill a 256 byte buffer with 0 to 255 and then call
promDevice.writeBuffer(buffer, 256, 0) or
promDevice.writeBuffer(buffer, 256, start & 0xfff00L)

[joaopauloap]

I got it to work. Yesterday I successfully wrote to 256 byte sector eeproms. I just needed to tweak the receiveFile function to advance the address only after the second packet was sent. I also improved my previous receivePacket code as well. I'll put the code from xmodem.cpp here and I'll create another thread to share this.

#include "XModem.h"
#include "CmdStatus.h"

// The original TommyPROM code used XModem CRC protocol but this requires parameters to be
// changed for the host communication program.  The default is now to use basic XModem
// with the 8-bit checksum instead of the 16-bit CRC error checking.  This shouldn't
// matter because communication errors aren't likely to happen on a 3 foot USB cable like
// they did over the long distance dail-up lines that XModem was designed for.  Uncomment
// the XMODEM_CRC_PROTOCOL line below to restore the original XMODEM CRC support.
//#define XMODEM_CRC_PROTOCOL

enum {
  // XMODEM control characters.
  XMDM_SOH = 0x01,
  XMDM_EOT = 0x04,
  XMDM_ACK = 0x06,
  XMDM_NAK = 0x15,
  XMDM_CAN = 0x18,
  XMDM_ESC = 0x1b,
  XMDM_CRC = 'C',
#ifdef XMODEM_CRC_PROTOCOL
  XMDM_TRANSFER_START = XMDM_CRC
#else
  XMDM_TRANSFER_START = XMDM_NAK
#endif
};

enum {
  // Misc constants for XMODEM.
  PKTLEN = 128
};

enum { RX_OK,
       RX_ERROR,
       RX_IGNORE };

//variables to handle 256 byte sector eeprom with the 128 byte packet of xmodem
bool flagFirstPacketReceived = false;
byte bufferPacket1[128];
byte bufferFull[256];

uint32_t XModem::ReceiveFile(uint32_t address) {
  uint8_t buffer[PKTLEN];
  int c;
  uint8_t seq = 1;
  uint32_t numBytes = 0;
  bool complete = false;
  int status;

#ifdef XMODEM_CRC_PROTOCOL
  Serial.println(F("Send the image file using XMODEM CRC"));
#else
  Serial.println(F("Send the image file using XMODEM"));
#endif
  if (!StartReceive()) {
    cmdStatus.error("Timeout waiting for transfer to start.");
    return 0;
  }

  while (!complete) {
    if ((c = GetChar()) < 0) {
      cmdStatus.error("Timeout waiting for start of next packet.");
      cmdStatus.setValueDec(0, "seq", seq);
      return 0;
    }

    switch (c) {
      case XMDM_SOH:
        // Start of a packet
        status = ReceivePacket(buffer, PKTLEN, seq, address);
        if (status == RX_OK) {
          // Good packet - advance the buffer
          if (flagFirstPacketReceived == false) {
            address += 256;
          }

          numBytes += PKTLEN;
          ++seq;
        } else if (status == RX_ERROR) {
          return 0;
        }
        // else ignore the duplicate packet
        break;

      case XMDM_EOT:
        // End of transfer
        Serial.write(XMDM_ACK);
        complete = true;
        break;

      case XMDM_CAN:
      case XMDM_ESC:
        // Cancel from sender
        cmdStatus.error("Transfer canceled by sender.");
        cmdStatus.setValueDec(0, "seq", seq);
        return 0;
        break;

      default:
        // Fail the transfer on anything else
        cmdStatus.error("Unexpected character received waiting for next packet.");
        cmdStatus.setValueDec(0, "char", c);
        cmdStatus.setValueDec(1, "seq", seq);
        return 0;
        break;
    }
  }

  return numBytes;
}


// This method it not very tolerant of communication errors.  If the receiver
// does not send a positive ACK for each packet or does not ACK the packet
// within one second then the transfer will fail.  Unlike in the dial-up
// days of old, this is designed to be run on a 3 foot cable betwee two fast
// hosts, so communication errors or timeouts are extremely unlikely.
bool XModem::SendFile(uint32_t address, uint32_t fileSize) {
  uint8_t seq = 1;
  int rxChar = -1;
  uint32_t bytesSent = 0;

#ifdef XMODEM_CRC_PROTOCOL
  Serial.println(F("Set the terminal to receive XModem CRC"));
#else
  Serial.println(F("Set the terminal to receive XModem"));
#endif
  while (rxChar == -1) {
    rxChar = GetChar();
  }
  if (rxChar != XMDM_TRANSFER_START) {
#ifdef XMODEM_CRC_PROTOCOL
    cmdStatus.error("Expected XModem CRC start char");
#else
    cmdStatus.error("Expected XModem NAK char to start");
#endif
    cmdStatus.setValueDec(0, "char", rxChar);
    return false;
  }

  while (bytesSent < fileSize) {
    SendPacket(address, seq++);
    address += PKTLEN;

    rxChar = GetChar(5000);
    if (rxChar != XMDM_ACK) {
      cmdStatus.error("Expected XModem ACK.");
      cmdStatus.setValueDec(0, "char", rxChar);
      return false;
    }
    bytesSent += PKTLEN;
  }

  // Signal end of transfer and process the ACK
  Serial.write(XMDM_EOT);
  rxChar = GetChar(5000);
  if (rxChar != XMDM_ACK) {
    cmdStatus.error("Expected XModem ACK to EOT, but received:");
    cmdStatus.setValueDec(0, "char", rxChar);
    return false;
  }

  return true;
}


void XModem::Cancel() {
  // Send a cancel and then eat input until the line is quiet for 3 seconds.
  Serial.write(XMDM_CAN);
  while (GetChar(3000) != -1) {}
}


// Private functions
int XModem::GetChar(int msWaitTime) {
  msWaitTime *= 4;
  do {
    if (Serial.available() > 0) {
      return Serial.read();
    }
    delayMicroseconds(250);
  } while (msWaitTime--);

  return -1;
}


uint16_t XModem::UpdateCrc(uint16_t crc, uint8_t data) {
#ifdef XMODEM_CRC_PROTOCOL
  crc = crc ^ ((uint16_t)data << 8);
  for (int ix = 0; (ix < 8); ix++) {
    if (crc & 0x8000) {
      crc = (crc << 1) ^ 0x1021;
    } else {
      crc <<= 1;
    }
  }
#else
  crc = (crc + data) & 0xff;
#endif
  return crc;
}


bool XModem::StartReceive() {
  delay(2000);
  for (int retries = 20; (retries); --retries) {
    // Send the XMDM_TRANSFER_START until the sender of the file responds with
    // something.  The start character will be sent once a second for a number of
    // seconds.  If nothing is received in that time then return false to indicate
    // that the transfer did not start.
    ++promDevice.debugRxStarts;
    Serial.write(XMDM_TRANSFER_START);
    for (unsigned ms = 30000; (ms); --ms) {
      delayMicroseconds(100);
      if (Serial.available() > 0) {
        return true;
      }
    }
  }

  return false;
}


int XModem::ReceivePacket(uint8_t buffer[], unsigned bufferSize, uint8_t seq, uint32_t destAddr) {
  int c;
  uint8_t rxSeq1, rxSeq2;
  uint16_t calcCrc = 0;
  uint16_t rxCrc;

  rxSeq1 = (uint8_t)GetChar();
  rxSeq2 = (uint8_t)GetChar();

  for (unsigned ix = 0; (ix < bufferSize); ix++) {
    if ((c = GetChar()) < 0) {
      // If the read times out then fail this packet.  Note that this check isn't
      // done for the sequence and CRC.  If they timeout then the values won't match
      // so there is not point in the extra code to check for the error.  The worst
      // that will happen is that the transfer will need to wait 3 timeouts before
      // realizing that something is wrong.
      cmdStatus.error("Timeout waiting for next packet char.");
      cmdStatus.setValueDec(0, "seq", seq);
      Serial.write(XMDM_CAN);
      return RX_ERROR;
    }
    buffer[ix] = (uint8_t)c;
    calcCrc = UpdateCrc(calcCrc, buffer[ix]);
  }

#ifdef XMODEM_CRC_PROTOCOL
  rxCrc = ((uint16_t)GetChar()) << 8;
  rxCrc |= GetChar();
#else
  rxCrc = GetChar();
#endif

  // At this point in the code, there should not be anything in the receive buffer
  // because the sender has just sent a complete packet and is waiting on a response. If
  // the XModem transfer is not started quickly on the host side, TeraTerm seems to
  // buffer the NAK character that starts the transfer and use it as an indication that
  // the first packet should be sent again.  That can cause the Arduino's 64 byte buffer
  // to overflow and gets the transfer out of sync.  The normal processing will detect
  // the first packet and will process it correctly, but the partial packet in the
  // buffer will cause the processing of the next packet to fail.
  delay(10);
  if (Serial.available()) {
    ++promDevice.debugRxSyncErrors;
    if (seq == 1) {
      // If any characters are in the buffer after the first packet, quietly eat
      // them to get back on a packet boundary and send a NAK to cause a retransmit
      // of the packet.
      while (Serial.available() > 0) {
        delay(1);
        Serial.read();
        ++promDevice.debugExtraChars;
      }
      delay(1);
      Serial.write(XMDM_NAK);
      return RX_IGNORE;
    } else {
      // Sync issues shouldn't happen at any other time so fail the transfer.
      cmdStatus.error("RX sync error.");
      cmdStatus.setValueDec(0, "seq", seq);
      cmdStatus.setValueDec(1, "rxSeq1", rxSeq1);
      cmdStatus.setValueDec(2, "rxSeq2", rxSeq2);
      cmdStatus.setValueHex(3, "calcCrc", calcCrc);
      cmdStatus.setValueHex(4, "rxCrc", rxCrc);
      Serial.write(XMDM_CAN);
      return RX_ERROR;
    }
  }

  if ((calcCrc == rxCrc) && (rxSeq1 == seq - 1) && ((rxSeq1 ^ rxSeq2) == 0xff)) {
    // Resend of previously processed packet.
    delay(10);
    ++promDevice.debugRxDuplicates;
    Serial.write(XMDM_ACK);
    return RX_IGNORE;
  } else if ((calcCrc != rxCrc) || (rxSeq1 != seq) || ((rxSeq1 ^ rxSeq2) != 0xff)) {
    // Fail if the CRC or sequence number is not correct or if the two received
    // sequence numbers are not the complement of one another.
    cmdStatus.error("Bad CRC or sequence number.");
    cmdStatus.setValueDec(0, "seq", seq);
    cmdStatus.setValueDec(1, "rxSeq1", rxSeq1);
    cmdStatus.setValueDec(2, "rxSeq2", rxSeq2);
    cmdStatus.setValueHex(3, "calcCrc", calcCrc);
    cmdStatus.setValueHex(4, "rxCrc", rxCrc);
    Serial.write(XMDM_CAN);
    return RX_ERROR;
  } else {

    ////////////// 256 byte buffer treatment
    if (flagFirstPacketReceived == false) {

      for (int i = 0; i < 128; i++) {  //keep the first packet bytes in bufferPacket1
        bufferPacket1[i] = buffer[i];
      }

      flagFirstPacketReceived = true;

    } else {

      for (int i = 0; i < 128; i++) {
        bufferFull[i] = bufferPacket1[i];  //pass the first packet bytes to beginning of bufferFull
        bufferFull[i + 128] = buffer[i];   //copy the second packet bytes to second half of bufferFull
      }

      if (!promDevice.writeData(bufferFull, 256, destAddr)) {
        cmdStatus.error("Write failed");
        cmdStatus.setValueHex(0, "address", destAddr);
        return RX_ERROR;
      }
      flagFirstPacketReceived = false;
    }
    ///////////////

    Serial.write(XMDM_ACK);
  }
  return RX_OK;
}


void XModem::SendPacket(uint32_t address, uint8_t seq) {
  uint16_t crc = 0;

  Serial.write(XMDM_SOH);
  Serial.write(seq);
  Serial.write(~seq);
  for (int ix = 0; (ix < PKTLEN); ix++) {
    byte c = promDevice.readData(address++);
    Serial.write(c);
    crc = UpdateCrc(crc, c);
  }

#ifdef XMODEM_CRC_PROTOCOL
  Serial.write(crc >> 8);
#endif
  Serial.write(crc & 0xff);
}

[TomNisbet]

Glad you were able to make it work. Thanks for sharing your solution.

[prlaba]

Thanks Tom, I’m using Atmel chips for all of my EEPROMs except the 29C040 4M (512K x 8) chip.  For that I’m using a Microchip SST39SF040 chip (faster access time than the Atmel chip). It’s programmed quite differently than the Atmel chip. The SST39SF040 uses 4K sectors for erasing a single sector (the entire chip can also be erased with a single command), but writes on a byte-by-byte basis.  Here’s the description from the datasheet (my italics): Byte-Program Operation The SST39SF010A/020A/040 are programmed on a byte-by-byte basis. Before programming, the sector where the byte exists must be fully erased. The Program operation is accomplished in three steps. The first step is the three-byte load sequence for Software Data Protection. The second step is to load byte address and byte data. During the Byte-Program operation, the addresses are latched on the falling edge of either CE# or WE#, whichever occurs last. The data is latched on the rising edge of either CE# or WE#, whichever occurs first. The third step is the internal Program operation which is initiated after the rising edge of the fourth WE# or CE#, whichever occurs first. The Program operation, once initiated, will be completed, within 20 µs. See Figures 6 and 7 for WE# and CE# controlled Program operation timing diagrams and Figure 16 for flowcharts. During the Program operation, the only valid reads are Data# Polling and Toggle Bit. During the internal Program operation, the host is free to perform additional tasks. Any commands written during the internal Program operation will be ignored. I read this to mean that the host can pass the data to be written one byte/address at a time. Here’s the datasheet, if you’re interested:  https://1drv.ms/b/s!AutOq5wvw8K5qex9wOUgxxU6wOaUgA I haven’t tried programming this thing yet, but it appears I should be able to just feed n sequential bytes of data directly to the chip (setting the address pins accordingly), one byte at a time, without having to manage multiple buffers. Your take? Paul

…

On Aug 12, 2022, 11:45 AM -0400, Tom Nisbet ***@***.***>, wrote: The current hardware and software design of TommyPROM already supports 19 addresses with a Nano - 16 from the shift register and 3 as direct I/O pins. I've used this to read 29C040 chips successfully. If you want to use a different Arduino, you will almost certainly need to change the code that writes to the pins. Most of this is in PromDevice.cpp. Your bigger problem is that the 29C devices are sector-based flash chips. You must write all of the byes for a sector in the same operation. Depending on the manufacturer of your chip this may be a problem. I have seen 29C040 chips with sector sizes of 64, 128, or 256 bytes. The smaller two shouldn't be an issue and may even work with the stock 28C code that TommyPROM uses by default. If not, there may be some small changes needed to the block programming algorithm - I haven't looked at those chips in a while. If your chip has a 256 byte sector then the problem gets a bit more difficult. The XModem protocol uses a 128 byte block size and the code just does a block write when a new chunk of data is received. This would cause the chip to erase the sector, write the first 128 bytes, and then erase the sector again before writing the second 128 bytes. You would need to modify the code to keep a second buffer and write them both at once as a single block to the chip. Let me know if you decide to move forward with this. I may be able to offer some guidance if you get stuck. Tom — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[TomNisbet]

I'm actually working on an SST39 driver right now. I've already managed to program one by adding the byte unlock sequence and changing the control line code a bit. I just need to add code that keeps track of the current sector and erase it before writing. This is a bit different from the 29C chips, where the chip automatically erases the sector with each write. The advantage to the SST39 chips is that you don't need to write all of your data at once.

I'm working on my real job at the moment, but may be able to get the initial SST39 code checked in today.

[prlaba]

Wow, you’re doing all my hard work! Does the TommyPROM UI allow for programming an individual sector?  If not, you could just erase the entire device with one command, no need to erase sector by sector. Paul

…

On Aug 12, 2022, 1:02 PM -0400, Tom Nisbet ***@***.***>, wrote: I'm actually working on an SST39 driver right now. I've already managed to program one by adding the byte unlock sequence and changing the control line code a bit. I just need to add code that keeps track of the current sector and erase it before writing. This is a bit different from the 29C chips, where the chip automatically erases the sector with each write. The advantage to the SST39 chips is that you don't need to write all of your data at once. I'm working on my real job at the moment, but may be able to get the initial SST39 code checked in today. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[prlaba]

I’m happy to field test your SST39 sriver, since I have some of those.  I think I have everything I need to build a TommyPROM. Your code is well designed, easy to follow. Paul

…

On Aug 12, 2022, 1:07 PM -0400, ***@***.***, wrote: Wow, you’re doing all my hard work! Does the TommyPROM UI allow for programming an individual sector?  If not, you could just erase the entire device with one command, no need to erase sector by sector. Paul On Aug 12, 2022, 1:02 PM -0400, Tom Nisbet ***@***.***>, wrote: > I'm actually working on an SST39 driver right now. I've already managed to program one by adding the byte unlock sequence and changing the control line code a bit. I just need to add code that keeps track of the current sector and erase it before writing. This is a bit different from the 29C chips, where the chip automatically erases the sector with each write. The advantage to the SST39 chips is that you don't need to write all of your data at once. > I'm working on my real job at the moment, but may be able to get the initial SST39 code checked in today. > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you authored the thread.Message ID: ***@***.***>

[TomNisbet]

I just checked in a first version of the SST39 code if you want to give it a try. It seems to work with a few quick tests anyway. You just need to comment out the PROM_IS_28C and uncomment the PROM_IS_SST39SF line in configure.h.

The burnByte code in the SST39 code keeps track of the current sector and does a sector erase whenever a write to a new sector is attempted. This means that is will just transparently work in most cases, but the sector will need to be erased manually if you are working in a single sector and want to write over data in that sector a second time. I re-purposed the Erase command to allow for manual erasing of an address range and moved the existing is_erased command to now be the Blank command instead.

the following test seemed to work:
z0 - erase and write a pattern at address 0
z40 - write a pattern at 40
d0 - shows the two patterns
z2000 - erase and write pattern at 2000
z0 - erase and write pattern at zero again
d0 - shows the pattern at 0, but it is now gone from 40 because the sector was erased.

[prlaba]

“driver” Paul

…

On Aug 12, 2022, 5:40 PM -0400, ***@***.***, wrote: I’m happy to field test your SST39 sriver, since I have some of those.  I think I have everything I need to build a TommyPROM. Your code is well designed, easy to follow. Paul On Aug 12, 2022, 1:07 PM -0400, ***@***.***, wrote: > Wow, you’re doing all my hard work! > > Does the TommyPROM UI allow for programming an individual sector?  If not, you could just erase the entire device with one command, no need to erase sector by sector. > > Paul > On Aug 12, 2022, 1:02 PM -0400, Tom Nisbet ***@***.***>, wrote: > > I'm actually working on an SST39 driver right now. I've already managed to program one by adding the byte unlock sequence and changing the control line code a bit. I just need to add code that keeps track of the current sector and erase it before writing. This is a bit different from the 29C chips, where the chip automatically erases the sector with each write. The advantage to the SST39 chips is that you don't need to write all of your data at once. > > I'm working on my real job at the moment, but may be able to get the initial SST39 code checked in today. > > — > > Reply to this email directly, view it on GitHub, or unsubscribe. > > You are receiving this because you authored the thread.Message ID: ***@***.***>