Understand the flash chip process better, restructuring the program

FLASH CHIP MORE COMPLEX THAN IT SEEMED

What I discovered was enough to explain the odd behavior of the chip I was working on. Working from the tables and timing diagrams led me to an oversimplified view of its operation, and thus my code in the Arduino wasn't sufficient to properly control the chip. 

The chip provides automatic programmed operations which includes the ability to chain multiple requests together while the chip stays in its mode, for example sector erase or program (write). In order to get it out of those modes I needed to issue a reset signal which tells the microcontroller in the chip to go to sleep so that it reverts to acting like a read only SRAM. 

Secondly, I thought I could just monitor the RD/BY# signal which shows when it is busy doing some operation like sector erase or program, but in fact I have to do a read of the data lines to get the status of the operation. 

Third, if an operation such as a program (write) fails, the chip stays in write mode and won't respond until it gets a reset sequence.

The automatic operation mode means that within a period of time the chip will treat new input as a continuation request. For example, when I send the codes, five writes of specific patterns to request a sector erase, after I send the sixth that gives the sector address, it will watch for 50 microseconds for additional requests. Those are queued up and once nothing new arrives for 50 us, it processes the entire batch. It appears that writing data bytes (a program operation) can similarly be stacked.

RECODING THE ARDUINO TO HANDLE THE CHIP SUBTLETIES

This means that I had to turn the data lines on PORT E to input while monitoring status, then back to output when sending commands. I also had to flip the OE# to see the results on the data lines. Specific bits have assigned meanings, some for showing an operation is in progress by flipping the value of that bit or inverting the value of the data bit that was written. Others are set when there is an error in sector erase or program (write).

The good point is that I don't have to depend on the RD/BY# line any more, other than checking for consistency when the other status bits indicate that an operation is complete. This is the trailing part of each operation and naturally paces the rate of commands to the chip to when it is ready to act upon them. 

For simplicity sake, I will NOT use the stacked capabilities of erase or program, instead issuing a rese after the status shows completion of the prior request. I will be cycling the chip between modes for every byte programmed or sector erased, slower than otherwise possible but safer. 

WORKING ON ASR-33 TELETYPES FOR A FEW DAYS

I will be diverted to the work on the teletypes for the next few days, although I brought the flash chip programming setup home so that I could do work if I have any idle time.