Don't use a length var for read_i2c_block_data, as odds are you're receiving more data over the bus than you're telling the hardware to expect and that causes misbehavior
Excuse me but this is wrong. The master defines how many bytes are transfered as it's providing the clock signal. There is no option in the I2C standard to let the slave tell the master how many bytes it will transmit (except making a first request to get just the byte count of the next request).
I2C considers a 0xFF to be a null or not-a-character, so as long as you're sending strings (which should always end with a 0x00) and never send a 0xFF as a character, you can simply read the buffer into a string until you hit a 0xFF.
Again this is not true. 0xFF is not a null character but it's simply what the master get if the slave is not sending anything at all. I2C is not a good transport interface for strings anyway.
So I added "volatile" to the data buffers, but no luck
I saw more problems with the "command" variable. Did you change that too?
@OP: Change your code to always send the 4 bytes and not only if the correct command was sent. Tell us if this helps.