Just going to update this post in case it may help someone in the future wo rking with this particular chip: AT89LP51ED2.
So, I finally got it working right. There are about 10 errors in the most recent Datasheet.
After much experimentation, I have discovered that the EEBUSY flag (EECON.0 ) is totally meaningless. If you test the condition of this flag, your cod e will either hang, or it will proceed even though the EEPROM write is stil l in-progress (and will screw-up everything after that point.) This is tru e whether you Page-write, or Byte-write the EEPROM. Depending on how quick ly you either re-access the EEPROM (read-or-write), or how soon after you a ccess FDATA, your code likely becomes unstable.
The only workaround I have found it so force a delay in the code of about 2 milliseconds to allow the EEPROM write operation (in the FDATA space) to c omplete. You do not need to delay for an EEPROM read.
I strongly suspect the underlying problem is that the Extended RAM space oc cupies the same memory address, and is distinguished only through the use o f different OPCODES. MOVX for EEPROM, and MOV @Ri for RAM. Without the af orementioned delay, you end up accessing RAM, and not EEPROM, with predicta ble unfavorable results. (In other words, the delay for the EEPROM write o peration is somehow entangled with the EEPROM Enable bit at EECON.1)
It appears that you can not turn off the EEPROM enable while an EEPROM writ e is in-progress, even though Fig. 3-16 clearly shows that you can.
There are plenty of additional errors and omissions in the Datasheet relate d to the EEPROM function:
For example, Figure 3.6 - There is no mention anywhere in the datasheet what "DMEN" stan ds for, or how to set it. Also, the external data memory map shows EXRAM = 0 for all but the "64K XDATA" configuration, but they really mean EXTRA M. And, this can only be set by your device programmer. They claim it can be modified while the code is running in the target, but this is complete BS. It simply does not work. You have to rely on the fuse setting during initial flash programming, or the default value ("0") if you're going to ma p EDATA or FDATA into the XDATA space, or just use the whole 64kB for FLASH (Code).
Also in Figure 3.6: They show "IAP = 0", which I assume means "In Applic ation Programming", but the datasheet is utterly silent on what this means. It appears nowhere else in the document other than being the title headin g for Section 23.4 . Furthermore, even if it DOES mean In-Application-Prog ramming, then the memory map is wrong anyway, because the setting of this f use (at initial flash programming time, and which has been conveniently ren amed "In-System-Programming", or "ISP") has no bearing on the EEPROM operat ing whatsoever.
Perhaps "IAP" is an acronym from the programming API, which is a totally se parate document. If so, then the datasheet should explicitly reference the API.
Another thing: And this isn't really an error, per se, but it's more of a "Gotcha!": The EECON register is moved to address 096H in this part, and no t 092H as it is in just about every other 8051 variant in this family that I'm familiar with. So, be sure to adjust that in your compiler / library, as needed.
More crap: Section 3.3.1 claims that all three members in this family (i.e .: AT89LP51ED2 / RD2 / and ID2 will support up to 60-62 kB of external memo ry when using the internally mapped memory -- EXCEPT that they don't bother to mention that the RD2 variant DOESN'T even have EEPROM capabilities, and so the entire 64 kB is actually available. (Atmel does allude to this on the cover page, and nowhere else, that the 4K EEPROM is avail on the ED2 an d ID2. So maybe they get a pass on that, but would it kill them to make it a bit more obvious by at least giving it a passing mention in the section
3 that deals with Memory Organization?) i.e., where it BELONGS!!
This is a mature part, and I've used it in plenty of projects before. I'm not sure why I've never run into all these EEPROM issues before with it , but maybe those earlier projects had outboard memories on I2C or somethin g? (I mean, other than a bad batch of parts, which I guess can happen to anyon e?)
Anyway, this project is done and I'll put a call into Atmel/Microchip (whoe ver makes this part?) and give them the entire list of errors.
You would think a mature part like this would have many fewer errors and om issions in its datasheet.