Interfacing 8051 with external ROM

[MrDL2394]

Good day!

I am currently using Multisim 14.2 to simulate/demonstrate interfacing the 8051 MCU to an external ROM (27C64E250-883). I wanted to upload the code to the external ROM (by checking the Load machine code file only into attached XROM in MCU Code Manager) and was able to confirm that using the memory viewer. However, the assembly code does not seem to work anymore with that configuration. I also tried wiring the ROM to the MCU but to no avail. I have attached a screenshot of the simulation I am currently working on. The assembly code is as follows:

ORG 0H
START: CPL P1.0 ; complement the bit value at P1.0
       ACALL DELAY ; call delay
       SJMP START ; do it again

DELAY: MOV R4,#01H
WAIT1: MOV R3,#31H
WAIT2: MOV R2,#255H
WAIT3: DJNZ R2,WAIT3
       DJNZ R3,WAIT2
       DJNZ R4,WAIT1
       RET

END

Is there something I am missing in the wiring connection or in the assembly code to make it work? Can Multisim simulate the signals in an actual hardware setup?

[GGoodwin]

Hi MrDL2394,

First, I would like to clarify something about your code although this is not your main problem. Do you intend to write

WAIT2: MOV R2,#255

or

WAIT2: MOV R2,#0FFH

instead of

WAIT2: MOV R2,#255H

Did you encounter an error message during assembly or did the tools that you used displayed a warning but proceeded to generate code?

Regarding your main problem, I don't have the application Multisim (Desktop), I am only a user of Multisim Live which has limited features especially for Free Subscription user like me. I don't exactly know how Multisim simulates circuits with MCU. As I understand, there must be a working circuit aside from a correct code in order to run the simulation successfully. If this is the case then your circuit may be incomplete.

First, you don't have a clock source since XTAL1 and XTAL2 are both left floating. You can connect a crystal network on these pins, you can use an oscillator module, or you may simply utilize a square wave generator. Second, with RST pin left floating, you don't have a RESET circuit. You can connect an RC network or a µP/µC RESET module/subcircuit to RST. This will make the MCU start properly. A simple RC RESET network can be constructed by connecting a 10 µF capacitor from RST to Vcc and an 8.2 kΩ to 10 kΩ resistor from RST to ground (GND). Depending on the exact MCU that you are using, you may be able to reduce the value of the capacitor and the pull-down may not be required. The positive terminal of the capacitor should be connected to Vcc while the negative terminal goes to RST. Manual RESET button can be added by connecting a normally open push-button switch across the capacitor. Further refinement can be made but I will not proceed with that right now.

You have to verify if Multisim requires these components for complete circuit simulation or if RESET and clock source for MCU can just be simulated in software as well. Note also that for newer 8051 MCUs, RESET and clock can be generated internally so you don't have to add them in your circuit.

Another flaw that I see in your circuit is the latch that you use to demultiplex the data and low-order address buses. You used a 74LS373, for this and other functionally equivalent circuit using bipolar transistors, install a pull-up resistor network at the eight output lines (which are used as A7 to A0). The EPROM that you are using might work without the pull-up network (check the specifications to be sure) but if you will expand your system, you are not always guaranteed that the devices will work. If you don't like installing the pull-up resistor network you can use a 74HCT373 or other functionally equivalent latch from 74HCT family.

Best regards,

G. Goodwin

[MrDL2394]

Hello GGoodwin,

Thanks for your reply and for pointing out that mistake in the assembly code, I will change it to:

WAIT2: MOV R2,#0FFH

However, I have tried incorporating your suggestions of adding the usual external components (XTAL for clock source, RC network for RESET, pull-up resistors connected to A0 to A7) in an actual hardware setup and it did not change the circuit's behavior in the simulation. I presume that Multisim simulates both the clock source and RESET functionality internally already.

To elaborate further, I have done the following test scenarios:

1) Program is loaded in MCU and EAVPP is floating: The LED blinks as expected.

2) Program is loaded entirely in ROM and EAVPP is grounded: The LED does not blink at all. The program is indeed loaded in the XROM (using Memory view) but the MCU cannot seem to access the program despite the external circuit made (please see attached image). The MCU memory view seems to indicate that PC is wandering beyond the expected last memory address of the program (higher than 12H). I was expecting that it should have been able to read the contents of the XROM.

3) Program is loaded both in MCU & XROM and EAVPP is grounded: In this case, I set the IROM of 8051 to 1 KB and intentionally made the program larger than that to see if the MCU will eventually access the XROM. It appears to have the same behavior as scenario no. 2, PC goes beyond 3FFH but does not read the instruction in XROM.

I am still not sure how to make scenario no.2 work in simulation. Could it be that Multisim is not capable of simulating the program placed entirely in an external ROM? I cannot seem to find anywhere or in the documentation how it is supposed to be done. I really hope that someone with the experience of using Multisim and interfacing an XROM with 8051 could give me some hints on how to go about it or at least point me to relevant documentation.

Thanks again for the response, it's much appreciated :))

[GGoodwin]

It seems like this

... I presume that Multisim simulates both the clock source and RESET functionality internally already.

---

is true. Based on this

To elaborate further, I have done the following test scenarios:

1) Program is loaded in MCU and EAVPP is floating: The LED blinks as expected.

---

and from your original post, simulation is running properly with program in internal ROM. However, if you will make further experiments with clock source and RESET circuits, I suggest these

• Use a Digital Clock Source (Square Wave Generator) first before a crystal network until you successfully run a simulation. You will connect the output of Digital Clock Source to XTAL1. XTAL2 is the output of the inverter used as Pierce Oscillator, it can be used to drive other light load(s) in the circuit. Meanwhile, of course, you would want to leave XTAL2 floating.
• Make sure that the RESET capacitor is initialized to 0 V and that the simulator is configured to used this initial voltage.

---

I am still not sure how to make scenario no.2 work in simulation. Could it be that Multisim is not capable of simulating the program placed entirely in an external ROM?

---

I cannot give a definite answer as of this time since I don't have Multisim (Desktop) and I've only read few of the previous posts of other members regarding this topic. It's possible that Multisim is initially capable of simulating code in internal program memory only and the capability to execute code in external ROM is a (very near) future upgrade, but I have not read any documentation or posting about this.

I cannot seem to find anywhere or in the documentation how it is supposed to be done.

---

Documentation might be scarce or hard to find but control of executing entirely from external program memory is simply through /EA.

The additional recommendations that I can give right now are:

• Change the value of A7..A0 pull-up resistor network to 10 kΩ. Again, this is not your main problem but if you will build an actual circuit this modification will help.

• Add another 10 KΩ pull-up resistor network to AD7..AD0 (which is also at the input side of the latch). There is a possibility of misinterpreting the specification and documentation about the presence and/or absence of internal pull-up devices in this bus.

• Verify the timing specifications (e.g., setup time, hold time, access time) for the EPROM that you used. You can try experimenting with other EPROMs even if the timing specifications for what you are currently using are within the proper range. You can try other 27x64 or, since you are currently testing very short program, 27x16s.

I currently run out time for this, I'll try to continue maybe after two days. You can post the results or any observation you made when you conduct further experiments.

[GGoodwin]

This is the continuation to my previous reply.

3) Program is loaded both in MCU & XROM and EAVPP is grounded: In this case, I set the IROM of 8051 to 1 KB and intentionally made the program larger than that to see if the MCU will eventually access the XROM. It appears to have the same behavior as scenario no. 2, PC goes beyond 3FFH but does not read the instruction in XROM.

---

You may want to try experimenting using both internal and external program memory again but with a code containing an explicit jump to external location. Like your third setup, Vpp/~EA will be strapped to ground. Basically, you will use the same circuit but I strongly suggest that you install 10 kΩ pull-up resistor networks to AD7..AD0 and A7..A0, this is to avoid possible sources of problems since I cannot closely monitor this forum and reply immediately. If you will continue experimenting with a clock source I hope you will follow my suggestion in the first part of this reply.

Here is my simple modification, consisting of only four (blue) lines, to your code:

ORG 0H

       LJMP XPMemStart ; jump to external program memory

ORG 1000H

XPMemStart:

       CPL P1.0 ; complement the bit value at P1.0
       ACALL DELAY ; call delay
       SJMP XPMemStart ; do it again

DELAY: MOV R4,#01H
WAIT1: MOV R3,#31H
WAIT2: MOV R2,#255H
WAIT3: DJNZ R2,WAIT3
       DJNZ R3,WAIT2
       DJNZ R4,WAIT1
       RET

END

I simply relocated the instruction blocks that perform the blinking of LED to the start of memory location occupied by the external EPROM. The instruction at the RESET vector is simply a jump to external program memory. I think the assembler you are using will allow you to use just JMP for SJMP and LJMP, nevertheless, I used an explicit LJMP.

You will load the binary image at address 0000H to internal memory. The size, if I am not mistaken, is only 3 bytes. You will then load the binary image starting at 1000H (4096 decimal) to the EPROM. Be careful in interpreting this, the binary image of the code starting at 1000H (4096 decimal) should be loaded to the EPROM memory location 0000H onward. To make it even clearer, the code for CPL P1.0 should be at EPROM memory location 0000H.

Because the EPROM is the only device attached to external memory bus, there is no need to add a decoder even though the EPROM is mapped to 1000H.

The EPROM starting address of 1000H is based on the original 80(C)51/87(C)51/89C51 and similar parts which contains only 4 KB of internal memory. I believe, based on you previous reply, that the simulation tools will allow you to modify that.

[GGoodwin]

In my previous reply, I mentioned that the binary image of the code starting at 1000H (4096 decimal) should be loaded to the EPROM memory location 0000H onward and that there is no need for additional decoder in the circuit. That is correct but I forgot that there is a need for rewiring. Instead of just appending the modification, I decided to describe the three options available when loading the binary image into the EPROM and the pros and cons of each option.

1. The binary image of the code starting at 1000H (4096 decimal) can be loaded to EPROM memory location 0000H onward. The necessary rewiring is to disconnect the EPROM's high address line(s), A12 (and higher for 27x128 and larger EPROMs), from the system address bus and strap it/them to ground. The advantage of this option is all EPROM locations can be fully utilized, this is at a minor expense of rewiring one (or more) of the device's address line(s).
2. The binary image of the code starting at 1000H (4096 decimal) can be loaded to EPROM memory location 1000H onward. The advantage of this option is no rewiring is needed. The lower 4096 EPROM memory locations, on the other hand, become unusable.
3. The binary image of the code starting at 1000H (4096 decimal) can be loaded to EPROM memory location 0000H onward and loaded again to EPROM memory location 1000H onward. EPROM's high address line(s), A12 (and higher for 27x128 and larger EPROMs), can be either connected to the system address bus or all strapped to ground. This makes the system flexible. However, aside from the two memory areas consumed by the code, another disadvantage of this option is the doubling of the effort of loading the binary image to EPROM.