When you have a microcontroller operating at, say, 25 MIPS, and a mechanical process operating a, say 1 KHz, the latter operates pretty accurately due to flywheeling, etc, but still has speed variations due to mechanical effects, eccentricity, termperature and load variations, supply variations, differences in material, etc, that amount to a very small percentage of that 1 KHz, but vary over a very large number of instruction cycles.

Now, you can find a closed-loop process by means of which to manage the mechanical process, or you can control it by making some modest assumptions, verified by measurement, of how those processes work. Once in a while, you'll be wrong about the range over which those mechanical effects vary, and that's where your synchronization breaks down. If, in addition, there's a communication task or two involved, e.g. one MCU has to tell another that a given event has occurred, things can get messy. Closed-loop methods are really the best, but ... they cost a bit more ... often quite a bit more ... than open loop controls. If you have to build a sensor that verifies via a closed loop that your stepping motor has finished making its step, then you're going to spend a bit of money verifying that, particularly if each step in the acceleration and deceleration curve is of different duration. As a result, you build a table of periods for a sequence of steps which gets you from velocity A to velocity B. If one or another of those is "off", you may, once in a while, miss a step, perhaps because of load variation or because of system resonances, or any of a number of other causes. Normally, a slight tweak of the period of THAT step will make the overall problem go away. Of course it could make it worse, but you normally know, after a while, which way to go.

Another sort of sync problem occurs when you have a fixed window within which you have to respond to an input, but you have no local control over the time at which the input occurs. If you go about your normal business in the "usual" sequence, you may, on rare occasion, miss a, input during one cycle in your default process, causing you to miss the earliest occurrence of your input. Now, monitoring more frequently might not help, since it lengthens your loop. Sometimes simply changing the point in the loop when the event is monitored can help, or, as I've seen frequently, reducing the rate at which it's monitored might help as well. This sort of thing involves simple and small changes, removing a call, or adding a delay, increasing/reducing a baud rate, simulation of none of which is easily applied. You sometimes just have to go in and tweak a few things.

That's very easy and straightforward with a debug monitor, and produces readily observable results.

RE