Hallo Lee,

bus contention, as described by you in your last posts, will indeed damage your devices!

Let's analyse some cases, where a damage can occur:

1. Your micro runs ill in such a way, that instructions are performed, never written by you. This will mainly happen, when Vcc shows undervoltage. A simple reset controller with brown-out detection will prevent this situation.

2. Your micro runs ill in such a way, that instructions are performed, which ARE written by you, but operation is in wrong sequence. This also is a typical failure, when Vcc shows undervoltage. But another reason can cause this, abnormal signals at Vcc or any port pin like it's ovserved with ESD events or other interference. Then, internal program counter gets a wrong address and sequence of instructions is wrong.
Reset controller with brown-out detection will help in the case, that undervoltage causes malfunction. Against abnormal signals at Vcc or port pins only filtering helps.
Anyway, even if sequence of instructions is wrong, this does not necessarily mean, that bus contention will happen. Only if your program contents the code that manipulates !RD line. So, in systems using memory mapping, port which performs !RD signal should NOT be used for other purposes, only for !RD signal.

There are two further recommendations:

a. Decode memory space in such a manner, that reagardless of actual address no more than ONE device can be decoded and enabled. So, carefully avoid any overlap of address space.

b. It's often wise to gate all enable signals by reset signal of reset controller. So, whenever there's a brown-out condition all memory mapped devices, which can drive data bus and cause bus contention are disabled. Even in power-up situation, when port pins need some miliseconds for getting reseted, bus contention is securely prohibited.

Kai