Dynamic length binary data parsing
Here are some things that may help you improve the quality of your code.

Don't handle message parsing in an interrupt

You don't explicitly say it, but from the context, it appears that you're attempting to parse a serially received message in an interrupt handler.  This is usually not a good idea.  An interrupt handler should be fast and do the minimum amount of work possible.  For serial message protocols, this typically means reading each character, putting it into a memory buffer (most often implemented as a circular buffer) and updating pointers.  Then the main routine that is NOT in an interrupt reads the contents of the buffer and does any message parsing/handling.

Don't parse until you have a complete message

In this case the message length appears to be 8 bytes (6 header + 2 trailer) plus the size of the enclosed data. It also appears that there is some kind of special marker for the beginning of the message.  So a quick check for the message parser would be something like this:


are there at least 8 bytes?
is the first character the message marker byte?


If the answer to either question is "no," it can't be a real message and so the data may be left in the buffer until more is received.  If the answer to both questions is "yes," then it might be a message.  The next steps might be:


does the message have at least 8+msg_length bytes?
is the checksum correct?


If the answer to both questions is "yes" then you can actually act on the message (typically by passing it to some higher layer protocol handler).

Use a state machine

The typical way to parse messages like this is to use a state machine. In this case the states might be:


waiting for message marker byte
receiving header
receiving data
receiving trailer


There are also often states for error and for timeout.

Avoid the use of "magic numbers"

This code is littered with "magic numbers," that is, unnamed constants such as 400, 512, 10, 5, etc.  Generally it's better to avoid that and give such constants meaningful names.  That way, if anything ever needs to be changed, you won't have to go hunting through the code for all instances of "5" and then trying to determine if this particular 5 means an offset into the message structure or some other constant that happens to have the same value.

Beware of buffer overflow

The allocation of a fixed 400 bytes for data might be OK, but if so, then you absolutely need to make sure that the message will fit in that space before copying it.  Failure to do so leads to the possibility of buffer overflow.