Invalid data on 80188 memory read

Hope someone with 80188 experience can help on this one.

I have a working 80188 design that has been in production for years. Works 99.99%

But with a board I'm using to develop on, when I read a memory mapped port ( not I/O ) the data that gets loaded into the AL register doesn't match the input port. I've looked at the 8-bit Adress+Data bus during the read and the data is correct as /RD goes high. But I get a different fixed value read into the '188????

The sw is in a simple loop, reading the port for ever. The data can change from day-to-day, but is always the same over several hours. The data read does not match the next or previous bus cycle.

The bus is multiplexed, unbuffered. Here is the loop:

0xCBE8:0x0941 C4 1E 1E 5C LES BX, Dword Ptr [0x5c1e] 0xCBE8:0x0945 26 8A 07 MOV AL, Byte Ptr ES:[BX] 0xCBE8:0x0948 88 46 FF MOV Byte Ptr 0xffff[BP], AL 0xCBE8:0x094B EB F4 JMP Short 0x941

The port is selected by one of the programmable chip selects, OR'd with /RD The data is read using a 74HC244 tri-state buffer.

The system has a 24Mhz clock, and I tried running it at 12MHz but got the same result. I also tried inserting a few wait states, with the same result.

TIA

Jim

Reply to
Jim Burke
Loading thread data ...

I think I see whats happening, I'm reading EBh which happens to be the opcode for the instruction following the memory read,

EB F4 JMP short 0x941

^ |--------------------------------------------- !!!!

I would guess then that the delayed /RD to my '244 buffer is too delayed and actually picking up the next opcode fetch. But I'm not sure about the execat bus sequence yet.

And yesterday, I was reading 00h, which makes no sense in this scenario.

Reply to
Jim Burke

not I/O )

correct as /RD goes high.

What processor are you using?

Reply to
Jim Stewart

80C188EB and a Signum System USB-186 emulator with a 80C186EB inserted in the socket.
Reply to
Jim Burke

for the instruction following the

actually picking up

This is just a guess ... The opcode for the following instruction will be read by the normal instruction pre-fetch mechanism of the CPU, and in many systems the parasitic capacitance of the data bus can keep the pattern for a short while, as long as it is not overwritten by something actively driving the bus. (This is why a simplistic memory test program I wrote a long time ago for an 8085 based data logger would correctly detect stuck bits, while at the same time reporting that an empty socket passed the tests with flying colors...)

If the chip-select/enable logic of you memory mapped I/O port is faulty or too slow to react, the CPU may be reading that lingering value. Check the setup and hold times of any logic related to the port. Adding wait states may cure the problem.

Roberto Waltman

[ Please reply to the group, return address is invalid ]
Reply to
Roberto Waltman

for the instruction following the

actually picking up

Damn good guess as I've seen the same thing.

He also needs to verify that there's enough setup and hold of the data by the data sheet. Just being valid at /rd rising might not be good enough.

Reply to
Jim Stewart

socket.

Did you notice that 80C188EB and 80C186EB have different memory bus layouts?

Is your memory-mapped address even or odd?

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

The EB was only a coincidence. Actually 88 is the opcode following the memory read.

Reply to
Jim Burke

Hi Tauno,

Yes, one is 8-bit the other is 16-bit. I inherited this system, and it works but for this problem, so I'm guessing somehow the '186 is jumpered/selected to run in '188 mode. If a '186 can't run in '188 mode, I'm really confused. :)

Even. A000:0004

More info: This design has been in production for years and works. The 8-pit port is actually an 8 bit dip switch. There have been reports from the field that the switch is 'flaky', so thats why I suspect the design is flaky.

It was working for me for 1/2 aday, then got bad reads, then got good ones later on again.

Reply to
Jim Burke

Data bit shorted to /RD?

Reply to
Tom Lucas

later on again.

Try hitting the chips in the address and data paths with heat (heat gun) and cold (freeze spray). That will often show up a marginal chip or timing design. Also, does the board fail without the emulator? You might have to write a bit of extra twiddle-an-IO-pin code to check that.

Reply to
Mike Silva

Jim, I tried to send you an email but it bounced. Is your advertised one real and I was just unlucky or is it an anti-spam method? I can't offer much help with this particular problem but I did want to chat to you about the 80188 in general. My e-mail is tlucas at autoflame dot com.

Reply to
Tom Lucas

Which is a damn fine email adress for using on usenet !

--
:wq
^X^Cy^K^X^C^C^C^C
Reply to
Ico

It is my belief that it has saved me from a spamming on occasions because it looks fake, however it is the company's name. Of course an autoflamer could be a useful tool in the spam battle - they can't say they weren't warned!

Reply to
Tom Lucas

... snip ...

You don't show the contents of the BP and DS registers, both of which will affect the destination. I am not sure anymore whether specification of BP forces use of SS in place of DS. With any normal calling conventions, the BP will not be constant, so the destination should vary all over the place.

--
 

 "A man who is right every time is not likely to do very much."
 Click to see the full signature
Reply to
CBFalconer

Yes, it does. The default segment register for any addressing containing BP will be SS, instead of the customary DS.

--
Tauno Voipio
tauno voipio (at) iki fi
 Click to see the full signature
Reply to
Tauno Voipio

CBFalconer wrote: Thanks for the replies.

  1. /RD shorted to a data bit? A. No. All data bits are free.

  1. BP and DS registers. In the 4 line code fragment, the 3rd instr. stores the result of the read into a local variable. dip_switch = *MemoryMAppedInput; They don't affect the port read AFAIK. Just load the AL register to a memory location.

I might try NOP'ing that instr out, just for ha-ha's.

I checked that no other chip selects were active during the read. Setup time before /RD goe shigh is > 40 nS, and hold time around 30nS Both within the '188 @24Mhz spec as I read it. T- CLIH from the manual is 3nS, the hold time.

  1. Doe sit do the same thing on a non-emulator board? I believe so. Both configurations exhibit the same failure. Everything works, but fo rthe communications which depend on the dip switch value.

Thanks again to all who posted.

Jim

Reply to
Jim Burke

same result.

For those who wher looking at the BP register: after the 1st line, ES = A000, BX = 0004 After the second line, AL = EB

So the read is already bad before line 3 stores AL in memory.

Reply to
Jim Burke

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.