I did find there are things that can corrupt the eeprom values, running too fast.
That sounds like they are not doing a good job of handling interrupts, typically if modifing an eeprom value you should halt interrupts for the duration, not doing so can cause this type of issue.
However that only happens if you write eeprom, I have no idea why grbl would be doing that during a run, so I suspect the problem is at too fast a setting, grbl is being ibterrupted during an interrupt process and ens up with a stack overflow, this could do anything and also reboot the device.
So definately worth checking eeprom values if experiencing eratic behavior, if you even can, depending on when interrupts are enabled you may not eben be able to get it to run.. continuous rebooting.
https://github.com/gnea/grbl/issues/142