The newly purchased AT89C52’s from a different vendor arrived in relatively short order. The original order from a Chinese eBay vendor still have not arrived (as of yet). That seller has issued a refund but from prior attempts to order AT89C52’s from what seemed to be different sources, has been met on a few occasions with eBay messages stating that I did not “meet that vendor’s seller criteria”. Seems the 1st vendor is selling under different seller names and has “black-listed” me from purchasing, at least those parts, from those various “vendor names”. In five sequential requests for confirmation of being”black-listed” from the 1st vendor, that particular question has never been answered nor even addressed. So I surmise that it is true. All I can say to those that wish to order from Chinese eBay vendors, and this is not a racist statement, is beware of those that offer “free shipping” but do not ship using the “ePacket” method of shipment. The “ePacket” method of shipment can be tracked on the USPS.COM (UNITED STATES POSTAL SERVICE) web site and show up within a day or two as having been “accepted” on the Chinese Post end. I am not saying that all vendors are attempting to scam buyers, as my experience has been that it is only a few. But a confirmation is that when the parts still have not arrived in 4 to 5 weeks, and the vendor is informed of the parts not arriving, those will vendors ALWAYS issue an immediate refund without question. They mark the item as “unpaid” so that a negative feedback against them cannot be lodged. And of course, the parts NEVER arrive. So, “buyer beware”.
Now, on to the testing of the 8052 SBC…
I had ordered another 5 pieces of the AT89C52, not the “S52” as before. They arrived and I immediately tested them in my TL-866 programmer. All but one tested good and the one that failed had a broken GND pin. Although these parts were packed on conductive foam, the foam was not cut squarely and two parts had pins hanging off the ends of the foam. I do not think the damage happened in shipping but likely in handling before shipment. After submitting photos of the missing pin and the shipping envelope, the vendor has offered to replace the item free of charge and re-send using the “ePacket” method as before.
The first thing I did was to program the MCS-BASIC V1.31 into the on-chip 8KB EEPROM. I had to insure that my address decoder properly decoded the 32KB RAM in DATASPACE at 0x000 to 0x7FFF and the off-chip 8KB EEPROM at 0x8000 to 0x9FFF. Upon startup, the auto-baud detection routine ran and I was met with the MCS-BASIC-52 greeting. From there, I entered a simple program and ran it. There was a slight delay after the RUN command was issued then the program ran. I then used the PROG command to save the program to the external EEPROM and was met with an “READY” signifying that the save was successful. I then issued the ROM3 command (it was the 3rd save by now), which did not fail, and listed the saved program. I ran that program from EEPROM and all was good. I then used the XFER command to transfer the program from EEPROM to RAM and issued the RAM command. The program listed and ran without error. So that proved that the EEPROM is addressed correctly and the that writing and reading also worked correctly. V1.31 has a new command called ERASE, which erases the contents of the EEPROM. It does not make use of the READY output on the 28C64 (pin 1).
One of the problems I ran into was not having a reliable RESET pulse being applied to the AT89C52. Since the ISP connection applies a RESET as does the reset switch, I fed both inputs to the PLD so as to be able to use either one to reset the AT89C52. In my initial configuration, I used combinatorial logic to drive the AT89C52 RESET pin. However, the inputs to the GAL22V10 have no hysteresis, which I suspected may be the problem. The photos below show an oscilloscope capture of the low-going portion of the RESET signal at the AT89C52 (pin 9).
Referring to the photo on the above-left, it can be seen that the signal lingers mid-rail for about 600 uS. The only requirement for the RESET pulse duration specified in the datasheet is that it needs to be active for at least “two clock cycles”. At 11.059 MHz, this is about 180 nS. Suspecting that the mid-rail linger was the problem, I decided to synchronize the combinatorial reset output with the AT89C52’s clock via the XTAL2 output, which was fed to the CLK input of the GAL22V10. Referring to the photo on the above-right, this seemed to help quite a bit. After looking at the resulting oscilloscope capture, I could see that there were distinct high and low transitions, not mid-rail lingering. As can be seen in the capture, that mid-rail lingering has been translated by the GAL22V10’s registered output as many short-duration pulses, which if they are affecting the AT89C52, it seems that it is only in receiving multiple reset pulses before it receives the final one. Now, admittedly, it is not the ideal solution but with the limited active hardware on the board, it is the best one I could come up with and only required the connection between pin 18 of the AT89C52 and pin 1 of the GAL22V10.
With the RESET sources synchronized to the AT89C52’s clock, the RESET pulse seemed much more reliable.
I left the 8052 SBC running overnight. When I got back to it the next afternoon, I seemed to be having a new issue with the 8052 SBC not resetting properly again. In looking a the RESET output (pin 15) of the GAL22V10, I could see that there was in fact, no RESET signal at all. The only thing that could cause this is if there was no active clock signal to the GAL22V10 for it to clock the output register, which was the case as it turned out. In probing with my oscilloscope, I could see there was no signal at the XTAL2 pin of the AT89C52. When I touched the (10x) probe to the XTAL1 pin, the oscillator started. The oscilloscope probe’s loading to ground is about 10 MΩ but I am unsure what the capacitive loading is. From the AT89C52’s datasheet, I could find no XTAL2 “drive” capability specified. When the AT89C52’s oscillator chooses to run, the output is within the GAL22V10’a VIH and VIL specifications. In my experience with the AVR MCU’s, the crystal output was always able to directly drive a buffer (or at least a single input pin) to be used as an on-board clock source. Apparently, not so with the AT89C52. The loading capacitors are 30 pF, which are within the specification of the AT89C52’s datasheet and thus not suspect. In looking over the GAL22V10’s datasheet, the input capacitance is 8 pF and the leakage current on the inputs is either 10 uA or 100 uA depending on the logic level of the input pin. I would not think this would be enough to load the XTAL2 pin to a point to stop the oscillator but it appears to be the case. Even in cases where the oscillator is running stable for a time, I was always able to halt the oscillator with a few sequential presses of the RESET switch.
I performed a research on various crystal oscillator implementations for microprocessors and microcontrollers and found an Application Note from INTEL®, AP-155 “Oscillators for Microcontrollers” helpful. Though it seems to be unavailable on INTEL®’s web site.
I decided to try and limit the input current to the GAL22V10 by using a series resistor and thus limiting the loading on the XTAL2 output. I tried 1 KΩ resistor and the circuit seemed to work but I noticed that the input signal to the GAL22V10 was not actually operating within the VIH and VIL limits. I then tried a 470 Ω resistor and the drive signal was better BUT the oscillator still stopped on occasion with sequential presses of the RESET switch. I thought perhaps the extra capacitance from the probe is what helped and that increasing the loading capacitors on the oscillator pins could be the solution. Through experimentation, I found that by using a 47 pF capacitor on the XTAL1 pin and 100 pF on the XTAL2 pin, (C9 and C10 in the schematic) that the oscillator became stable with nearly a rail-to-rail swing on the XTAL2 pin. The confirmation of the stability of this simple fix was that multiple presses of the RESET push-button switch never stopped the oscillator.
On another note, the power consumption that was about 230 mA when the SBC was running with an INTEL 8052AH is now 150 mA using the AT89C52, which was expected.