Strictly necessary cookies are on by default and cannot be turned off. Functional, Performance and Tracking/targeting/sharing cookies can be turned on below based on your preferences (this banner will remain available for you to accept cookies). You may change your cookie settings by deleting cookies from your browser. Then this banner will appear again. You can learn more details about cookies HERE.
Strictly necessary (always on)
Functional, Performance and Tracking/targeting/sharing (default off)
You don't need to have a write protect pin at all. Just pull it high or low on your EEPROM chip depending on what state is active. Toggling of P1 will occur in the boot up/download process regardless, I don't personally know of any way around that. But after boot the pin is all yours to use.
Just expect some garbage data on the PUART during boot.
If you reference the datasheet, there are a few pins that can drive additional current, those are recommended for LEDs. A very small LED, however will be fine on the other pins. Yet a very large LED may even overdraw the expanded 16mA pins.
One possibility to protect from corruption would be to attach your WP pin to another GPIO (13 or 14) and toggle those just prior to every EEPROM write.
This wouldn't fix the problem of getting garbage on the PUART when you write EEPROM. That can only be fixed by writing your own low-level driver to interface to the EEPROM using raw i2c reads/writes. This is a lot of work but safe if you don't try to write into off-limits memory locations. *this won't fix garbage on PUART at boot up. Boot up will always use its own driver and you can't turn off WP without editing extremely low level code in the stack.