Here is a bin for clues as to why the programming sequence for the Maxtor 28LV010 fails for these special addresses.
The datasheet:
http://about.maxwell.com/pdf/me/product_datasheets/memory/28LV010_Rev6.pdf
from
http://about.maxwell.com/microelectronics/products/memory/eeprom/28LV010.asp
This shows that these addresses are used to unlock the "software protection mode". It seems unlikely that they are completely reserved, however. Most likely we are programming it incorrectly and just haven't figured out the mistake yet. To that end:
The part is a Mitsubishi part, actual part number HN58C1001, which has two AN's at Maxwell:
http://editors.maxwell.com/microelectronics/products/_components/memory/28LV010/app_notes.html
For minor SEU's:
http://editors.maxwell.com/microelectronics/support/app_notes/eeprom_error.html
For why does the documentation suck so much:
http://editors.maxwell.com/microelectronics/support/app_notes/hitachi.html
A search on the Hitachi part number gives links to a "Renesas" datasheet which seems pretty similar to the Maxwell one:
http://documentation.renesas.com/eng/products/memory/rej03c0145_hn58c1001.pdf
That datasheet apparently says that the part ships with software protection off, so the algorithm that we implemented to turn it on all the time may be causing some of our trouble. It also gives a lead for tech support questions.
Earlier, more floundery searching uncovered this datasheet to a different "LV010" part which is by a different manufacturer, and seems to work slightly differently despite having a similar pinout. The key discoveries here are that the software data protection feature is industry standard, and that it is implemented differently in this part than in hitachi's.
http://www.datasheetcatalog.org/datasheets/560/181909_DS.pdf
http://www.atmel.com/dyn/products/product_card.asp?part_id=1911
http://www.atmel.com/dyn/resources/prod_documents/doc0395F.pdf
