Plenty of things.

Is the part able to keep up with the incoming serial stream of data? If the data is garbled, does your firmware check for that and take appropriate action, or does it assume incoming data will always be received correctly and possibly do unpredictable things when that assumption is incorrect? Perhaps you're messing up the stack and the program is suddenly branching to some higher code address where there's no code until the program counter wraps around to 0000h and performs what you might interpret as a reset when actually it's just wrapped around and started at 0000h again.

As usual, break down the problem and find the minimum amount of code that is necessary to cause the problem. If you have an input routine, make the input routine the only thing that executes. That is, receive the input but just discard it and wait for the next input. If that works, then slowly start adding code that interprets the input string and see when the program starts failing; if the input routine all by itself causes the reset, then you can be pretty dang sure the input routine has a problem.

That kind of process of elimination should let you figure out what part of the program is causing the problem and allow you to focus on that.

Regards,
Craig Steiner