@fgrieu is right. I concur with the recommendation to use CMAC. That is a simpler, more general solution. Also, if space is at a premium, you can probably truncate the output of CMAC to 8 or 10 bytes, while still receiving adequate security.
One remaining vulnerability is that this scheme does not prevent an attacker from replaying, re-ordering, or deleting messages. If you send messages A,B,C,D, the attacker can arrange for the recipient to receive D,B,C,B,B (for instance). If you want to defend against that, you could use a sequence number (or possibly a timestamp).
Another vulnerability arises if you use this key for multiple connections. For instance, let's suppose Alice, Bob, and Carol share a single CMAC key. Then if Alice sends message M to Bob, the attacker can arrange to redirect the message to Carol and make Carol think that Alice sent M to her. One defense is to never reuse the same CMAC key (make it unique to a pair of endpoints and a direction). A different defense is to include the identity of the sender and the recipient in the input to CMAC, i.e., you compute T = CMAC(K, sender || recipient || message) and use T as the authentication tag. This solution does not increase the size of the packet, so it is essentially free.