How can you assume that it is the serial communication that fails, and not something else?

Any problem (embedded program, PC program, problem with car, ...) has to be broken into sub-problems and tested. When you find a sub-problem that fails, then you see if it is trivial enough to be fixed, or if you need to continue the sub-division.

How do you know that processor 1 can send? With correct baudrate? Correct data sent?

How do you know that processor 2 can receive? Correctly decode?

How do you know that processor 2 can send? With correct baudrate? Correct data sent?

How do you know that processor 1 can receive? Correctly decode?

How do you know that processor 2 can drive the stepper motor?

When you test a complete system, the only result of a failure is that the "system" doesn't work. It is then up to you to split that system into small enough boxes to find which box/boxes that fails.

When you have a situation that one set of processors works, and another doesn't, then you are home free. It is far easier to locate a problem when you have one setup that works and one that doesn't. All you need to do is compare the behaviour of the different boxes between the working and the failing setup.

If you already have done sub-system tests: Where are your test reports? You should not ask for help unless you also supply all information about what tests you have already done, and the outcome. We don't have access to the system, so we can't perform the tests for you...