Phillips P89c669

Hello,

has anybody dealt with the issue phillips refers to as CORE.3 problem in the microcontroller's errata sheet? CORE.3: MOVX @EPTR instruction produces unwanted activity on ALE and PSEN pins

Introduction: While MOV @DPTR can reach only 64 kB of external data, instruction MOVX @EPTR can access

up to 8 MB - 64 kB of external data.

Problem: When MOVX @EPTR is used for external memory access in a system with ALE active all the time

(AUXR.0=0), there is additional activity on PSEN pin after the read or write pulse. In a system where

ALE is active only when access to external memory is performed (AUXR.0=1), there is extra activity

on ALE and PSEN pins after the read or write pulse.

Workaround: None.

If someone decides to use external memory with this microcontroller, isn't there a possible unpredictable behaviour with all the "extra" activity? Since there is no workaround, does this mean that the only option is the Universal Pointer and EMOV? I would appreciate any help..

Thank you beforehand

--
Dimitris Stafylarakis
Electrical Engineer
Reply to
Dimitris Stafylarakis
Loading thread data ...

On Mon, 24 Jan 2005 17:23:40 +0100, "Dimitris Stafylarakis" wrote in comp.arch.embedded:

I haven't used this micro at all, but from what you posted I don't see much of a problem.

I could a real concern if the additional activity was on the WR pin, as it could cause an overwrite of memory or an erroneous setting in a memory-mapped I/O device.

But what you are quoting only applies to ALE and PSEN. It appears that at most you will generate an extra read from your program storage device (ROM/EPROM/flash), during a period when the micro is not actually using the bus, so unless you have external bus drivers there shouldn't even be any bus contention.

The only likely problem I can think of is if the timing between the next real ALE and real PSEN is too short for your address latch and program memory device, so the next instruction fetch doesn't read the proper instruction.

Are you having this problem, or are you anticipating some other? Are you just reading a data sheet, or trying to solve some problem you have on an actual board?

--
Jack Klein
Home: http://JK-Technology.Com
 Click to see the full signature
Reply to
Jack Klein

I'm only reading a data sheet right now. I only have one program flash in the design, so hopefully RD and WR stay high and thus create no bus contention with the data memories.

I am mostly worried about the timing issue, since program memory timing requirements for the specific microcontroller (and configuration) are pretty tight. Is there a possibility for an incorrect read? Or if the PSEN pulse is short enough there will be no memory read?

I am thinking of disabling the program memory and enabling it explicitly for when memory operations are intended for it. Do you think this will solve the problem?

Many thanks for your concern

--
Dimitris Stafylarakis
Electrical Engineer
 Click to see the full signature
Reply to
Dimitris Stafylarakis

You need to ask philips if there is any operational impact, for your application. This is a poor errata, as it does not state the severity of the issue. They do not say if incorrect code fetch results, or if memory address failures occur - important questions. You may be able to simply ignore the issue, unless you expect to externally use the ALE result, for example. (rare)

-jg

Reply to
Jim Granville

I agree it is a poor errata, and this implies that they haven't tested it thoroughly, but I will give it a try.

Do you think my solution would limit the extent of the problem? I am thinking that by address-decoding, it will reduce the possibility of having an incorrect code fetch, to only if a MOVX was performed to/from the program code flash itself. (up to now I had CE grounded permanently)

--
Dimitris Stafylarakis
Electrical Engineer
 Click to see the full signature
Reply to
Dimitris Stafylarakis

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.