Slow EEPROM reduces maximum oscillator frequency

In my previous post, I had written about having difficulties with the AT89C52’s oscillator being unstable and how I cured that issue.

Once I had achieved a stable oscillator, I increased the clock to 20 MHz.  All seemed to work properly.  I was able to write a BASIC program and save it to EEPROM using the PROG command and then I was able to run that same program from EEPROM as expected.  However, on a few occasions, the saved program ended up with hard-errors in it.  Looking at the saved program, one could see that some characters had changed and that in fact, the program had been a little trashed.  Erasing the EEPROM and saving again seemed to cure the problem but coming back to the project overnight and similat errors occurred.  At first, I thought that it might be a bad EEPROM, so I used a different one but the same type of “trashed saved program” errors occurred.  I even pulled the EEPROM to read in my TL-866A and I could see that a byte had in fact, changed.

I figured that it HAD to be the access time of the EEPROM getting in the way but I had not actually calculated the required timings to verify this. Well, I finally set up a spreadsheet to do so.  I used the timing formulas from the AT89C52 datasheet since those are the only timing variables that will change depending on the clock speed.

From the AT28C64-150’s datasheet, it can be seen by the”CE to output delay” parameter, that the data will be available no more than 150 nS after the CE line goes low.  The “Address to output delay” parameter is the same as the “CE to output delay” parameter of 150 nS.  Since I am using a GAL22V10D-15 to decode chip-selects and output enables for the RAM and EEPROM, I must take into consideration the propagation delay for the “Input or I/O to Combinatorial Output” parameter, which is 15 nS maximum.  What I found was that the 150 nS EEPROM was exactly at the maximum access time of 150 nS required for proper operation with the AT90S52 at 20 MHz, which explains the funky intermittent failures.  At 16 MHz, the EEPROM access time is within the required minimum timing.

Now, one may be asking “What about the RAM?  Is it not affected as well?”  The answer is “no”, because the RAM I am using is static and has a 15 nS access time.

Below are screen prints of the spreadsheet I used for this timing calculation.  On the left is the 20 MHz timing and the right is the 16 MHz timing.

Memory access timing at 20 MHz

Memory access timing at 16 MHz

Here is the spreadsheet file in XLS format.

Unless I decide to purchase some 120 nS AT28C64’s, I’ll leave the AT89C52 running at 16 MHz.

Still awaiting the AT89S52’s to arrive…

Software development for the 805x series

While working with my now working 8052 SBC, I spent some time testing with the BASIC-52 (v1.31) program.  One of the things I noticed is that the default value for the XTAL variable is set for 11.0592 MHz.  In looking at the source code, which is written in assembly, I found where the default value is stored and was able to change it.  However, I needed a way to re-assemble the source code into a binary to load into the AT89S52’s on-board FLASH memory.

I run Linux all the time and use it for everything. Currently, I am running Linux Mint 13 (LTS) but also have a WINDOWS® XP virtual machine running so I can develop for the AVR series of MCU’s.  For the 805x series, I have the limited “free” version of Keil’s uVision IDE, which runs under WINDOWS® and supports the legacy 805x MCU’s but it is limited to some 2KB of producible program code.  The Keil uVision assembler does directly assemble the BASIC-52 source code without modification.  The nice thing about KEIL’s IDE is that it also has a simulator for debugging code.

I REALLY want to assemble code under Linux and there are several open-source assemblers.  Most are outdated and must run under DOS (or a DOS-box under WINDOWS®).  I could run DOEMU or DOSBOX under Linux but that would be inefficient and there are some open-source Linux alternatives like as31, as8051 (asxxxx), asem51, etc.  A web search for these will yield their download URL’s.  But none of these directly assemble the BASIC-52 source code without some modification.  I really did not wish to modify the original source code in that manner though.  I did finally stumble across the asem51 assembler, which I found assembles the BASIC-52 source code without modification thus it is compatible with INTEL’s (and KEIL’s) DOS andWINDOWS® based assemblers.

BTW: the modification for setting the default XTAL frequency in the BASIC-52 source code is located around line 5830 in the version 1.31 source code.  Using the Linux command line version of the open-source minipro software for the TL-866A programmer also allowed me to reprogram the AT89S52 using the ICSP interface.  Except for a decent Linux-based debugger, I now am able to assemble and download my code into the AT89S52 without removing it from the PCB.

I’ll also note that the sdcc compiler is Linux compatible and will compile “C” code and has the ASXXXX assembler (written by Alan Baldwin) bundled with it.  As I stated, though the ASXXXX assembler is not directly compatible with the INTEL assembler, so existing 805x assembly code may need some modification to assemble without errors.

Peace and blessings.