Well, for one, the description of your scheme is not a scheme description. This is just a collection of vague intents. The description of a cryptographic scheme must be such that by reading the description alone, I could write an independent implementation that interoperates with yours. A good description looks like this. Or that.
Also, in your description, you don't actually say how you, you know, encrypt things. You seem to allude to some key derivation scheme from which you obtain "vectors" that appear to depend on the shared secret, but not on the data itself. What these vectors do, and how the data is encrypted and decrypted, is unclear.
In any case, designing your own cryptographic algorithm is a bad idea for the main reason that it is extremely hard to come up with a secure algorithm. Most of the training in cryptography consists in understanding just that: making a secure algorithm is a hard endeavour. The conceptual reason for that is that there is no test for security. The best we can do is to write down a complete and detailed specification (including a reference implementation, test vectors, and a heavy rationale for why it might be secure) and then submit that to a bunch of cryptographers and let them try to find flaws. It takes dozens of cryptographers, and several years of effort. This is why that kind of job is done through organized "competitions" like it was done for the AES.
A ten-line question on security.SE cannot be considered to be a reasonable alternative.
Moreover, most situations that warrant encryption (to ensure data confidentiality) also need something to guarantee integrity, because attackers are evil, don't play "by the rules", and may try to alter the data in transit, possibly to learn things about the data and keys based on how the systems behave when facing the altered data. Integrity is obtained through the use of a MAC. Combining encryption and a MAC securely is harder than it looks, so, there again, it is a job for competition-powered cryptographers (usual recommended solutions are GCM and EAX, but there is, indeed, an ongoing competition to get something better).
And when you have a good protocol (a secure assembly of secure algorithms) that should fulfil your needs, then you are not done yet; you must still get an implementation that is correct, robust, efficient, and (crucially) does not leak information. Side-channel attacks can be particularly deadly for careless code in embedded systems. There again, this is a matter of science and also a lot of skill, that cannot be improvised.
To sum up, you are in need for, at least, some serious help from a professional cryptographer (no, I am not for hire at the moment). Unless you are in a case where the data you want to protect is uninteresting, which ensures ultimate security: nothing protects data more than making the data so boring and useless that nobody actually bothers to try to access it.
