But your sendProtocolToMaster() is trying to send multiple bytes to the master, without support for any synchronization.

You have an infinite loop waiting for an acknowledge from the master. But if the master doesn't get any data, the master will not know that it should send an acknowledge. And if the master gets tired of waiting, it will try to address the board again - but your sendProtocolToMaster() will still try to continue with the ongoing transfer, ignoring that the master tries to resynchronize the transfer.

If you are in sendProtocolToMaster() or any loop in any function called from it, when you receive a new address byte (this or any other slave), you should have sendProtocolToMaster() end immediately and then - based on which slave address taht was received - decide if you need to restart the failed transfer or if you should sleep until this slave is addressed.

Your current code has the following logic:

Me: What is your name?
You: [garbled text] ...
Me: Sorry - didn't hear. What is your name?
You: [continuing with previous answer] ... umar.

End result - I don't manage to pick up your name.

Me: What is your name?
You: [garbled text]
Me: Sorry - didn't hear. What is your name?
You: [restarting the answer] My name is Praveen Kumar.

End result - I do catch your name.

Your transfer protocol must support that any byte sent from master to slave is lost or have bit errors.

Your transfer proocol must support that any byte sent from slave to master is lost or have bit errors.

Your transfer protocol should not allow the slave to send the answer to the wrong question, which would confuse the master. So it might be good if messages have checksum. Or if at least the answer from a slave repeats the command it thinks it is answering. And if you don't have checksums then you should really require two consecutive reset commands before restarting a slave - and the master should be able to see on the acknowledges if the slave performs the reset or not.

Your transfer protocol should support a transfer error even of the address byte. The slave that got accidentally activated (but doesn't have the TX line wired to the master) must gracefully stop the transfer when it doesn't receive an ack from the master. A slave that did not see its address should be able to respond on the next resend from the master.

Your current code just is not robust. And you do see the result of having a protocol that isn't robust.

For every single state the master or the slave can be in, you should consider what alternative ways there can be to leave that state. That includes things like:
- expected data received.
- unexpected data received.
- timeout because nothing is heard from the other side.

Your code "while(!data_ack);" does only work if you get the expected byte from the master. If the master sends a byte that isn't an acknowledge, you just stay in your loop without caring what the board received. If the master doesn't send anything at all, your slave stays in the loop indefinitely.

Are you surprised that the slaves sometimes seems to hang and requires you to send a command that makes the receive ISR jump to address zero?