Controller unresponsive after using the pause or stop buttons

There are some rare instances when the controller becomes unresponsive after using the pause or stop buttons.
A little background. The controller we use is built off the open source Buildbotics project that existed for a few years before Onefinity’s inception. They use a raspberry pi 3b (released in 2016). It uses a Broadcom BCM2837 chipset.
While a file is running, it streams the Gcode from its CPU through the serial bus to the custom board chipset to the motor drivers. The chipset used on the custom board is an 8bit chip. There is a buffer of code that gets sent as the pi can send data faster at times than the chipset can process. This is fine when a file is executing as the data just sits in a waiting state and is used when the time for it to execute itself comes. When pause or stop is pushed, the Raspberry Pi recognizes the command and stops sending the data, however, the buffer from the Pi’s chipset to the custom 8bit chipset is still ‘full’ and takes a bit to process and clear. If another command is given before this buffer of code is cleared, the pi ‘thinks’ the machine is busy, will try to execute another code and get ‘hung’ or stuck in ‘jogging’ status.
If you watch the ‘status’ indicator when hitting pause or stop, you’ll notice that it will flash yellow and state ‘busy’ for 1-60 seconds (depending on how much data is in the buffer queue). During this yellow ‘busy’ state, it’s important to let the status clear before touching any input buttons (or using a joypad to jog). If not, you will most likely experience the controller lock up in ‘jogging’ status and become unresponsive.