I am writing a code to interface 4 SSD with AT89C51 at Port 2 and Port 0. Port 2 is used to select the SSD and the Port 0 lines act as data lines to SSD (through ULN2004). I have written code for the same. And works as expected in keil4 simulator. But the real problem is that the code does not work on AT89C51 IC. So i modified the code to Turn-On and Turn-Off the port pins of all ports. But nothing happens.
Instead square wave is generated on Port 2 pins, such that square wave frequency at P2.0=x, P2.1=2x, P2.2=4x, and so on...(Very typical behaviour). Other port pins remain high.
so i checked the ALE signal, which goes high once every 25mSec. The crystal osc frequency = 12MHz. (i am worried about ALE signal)
The following is the simple code that i programmed just to turn-on & turn-off port pins. Port0 has pull-up resistors.
#include<intrins.h> #include <REGX51.H> bit flg=0; void main() { SP = 0x50; P0 = 0; TMOD = 0x01; //Timer1 - Counter Mode, 16Bit Counter. Timer0 - 16Bit Timer TCON = 0; TH1 = 0; TL1 = 0; TH0 = 0xF6; //F63C To generate delay of 2.5mSec TL0 = 0x3C; //D8F0 to generate delay of 10mSec //FC18 to generate delay of 1msec IT0 = 1; //Interrupt0 -> Negative Edge Triggerred IE = 0; //Disable all interrupts IP = 0; IE = 0x82; TR0 = 1; while(1) ; } void TIMER0_ISR(void) interrupt 1 //5msec interrupt for 7-segment display. { TR0 = 0; TH0 = 0xF6; //F63C To generate delay of 2.5mSec TL0 = 0x3C; //D8F0 to generate delay of 10mSec //FC18 to generate delay of 1msec TR0 = 1; flg = ~flg; if(flg) { P0 = 0xFF; P1 = 0xFF; P2 = 0x00; P3 = 0x00; } else { P0 = 0x00; P1 = 0x00; P2 = 0xFF; P3 = 0xFF; } }
I program the IC using ALL-11 programmer. The hardware is ok.
PS: Have worked on P98V51RD2FN and ARM, Cortex controllers also. But have never faced such a problem.
Target Options: Xtal(MHz) = 12.0 Memory Model = Small: Variables in DATA Code ROM Size = Small: Program 2K or less Operating system: None
Use On-Chip ROM(0x0-0xFFF)
Generate Hex file box is also checked. And i convert the Hex file to Bin file and program the ic using ALL-11 Programmer.
The hardware is ok.
It might be OK, but it's not doing what you want. Most importantly, it's pretty obvious that the state of the /EA pin is different from what you assume it to be. Your uC is running from external code memory, but your linker settings claim it should be running from internal memory. That is why it shows pulses on ALE. And what you see on P2 is the high byte of the addresses being fetched.
Yup. I found that the !EA pin was kept floating. connecting a 10K pull-up did it. It wasted 2 days. Unfortunate.
But then, the hardware works fine. A Frequency counter is implemented on the same hardware, with same IC without any additional jumper/cuttings. I had spotted the floating !EA, the very 1st day. But could not raise a suspicion as it already had some code working on it (for years). But i am astonished how it all works well with only the code change!! (I dont think software can control the !EA pin) Comment please....
Have you taken a look at fuses in the chip documentation?
a look at fuses in the chip documentation Do the same chips (from same manufacturer and same part no.) differ? Some chips detecting the floating pin (!EA) as logic level 1 (pulled-up internally) and the remaining some from the stock detecting the floating pin (!EA) as logic level 0!!!
You are answering a question with a question.
What does the "Lock Bit Protection Modes" table of the chip datasheet tell you? Or the section "Program Memory Lock Bits"?
What route - besides this forum - are you exploring to solve this problem?
Some chips detecting the floating pin (!EA) as logic level 1 (pulled-up internally) and the remaining some from the stock detecting the floating pin (!EA) as logic level 0!!! nothing unusual about that. That is why the state of a floating pin is 'undefined'.
Erik
Lock Bit Protection Modes Thanks for pointing out that. Dont think that this was in the original 8051 architecture. Didnt refer to AT89C51 user manual untill you pointed it. (my ignorance, sic).