Securing communication between limited embedded systems
A rule in cryptographic protocols is to never implement them on your own. Unfortunately I did not find anything that matches this use case.

Have you considered DTLS?  That tries to address the same problem (except for time stamps; that could be added by inserting the time stamp in the datagram), and already has things thought through.  Another possibility would be IPsec; however DTLS looks closer to addressing the problem you have (unless the data traffic you're protecting is IP traffic).
That said, here are some thoughts on the protocol you outlined:

What happens if two sequential messages are dropped (e.g. received incorrectly)?  Will the two sides realize what happened, or will they proceed to drop all subsequent messages (because of the 'nonce has to increment no more than 2' rule)?

Presuming they attempt a rekey, how is this coordinated?  If one side thinks they haven't rekeyed yet, and the other side thinks they are, what will happen to messages encrypted with the old key?  We find it generally useful to include a 'which key this is encrypted under' tag with the ciphertext (in DTLS, this is the 'epoch').

Can your communication channel reorder messages?  I suspect it can't in your case, but if it can, you should think about how that should be handled.

What happens if someone injects a previous (valid) handshake message?  How will that confuse things?

In the data encryption path, you use CBC encryption and CMAC integrity.  While this is a workable solution, this is prone to various padding attacks if they aren't integrated correctly.  Current fashion is to use an AEAD mode (such as GCM or Chacha20/Poly1305) which does both.

Is the encrypted traffic unidirectional or bidirectional?  If traffic goes both ways, do you use the same set of keys to protect both sets of traffic?

&quot;If anything is not as expected, Handshake is sent again, then message is sent again with newly exchanged parameters.&quot; - how does that work?  If the receiver decided it didn't like the message, how does the sender know to resend it?