Firmware coding - applicable standards
Not that I have really found after writing code for about 35 years.   There are some guidelines about what NOT to do, but it doesn't build in quality.  "Quality" in software is a very intangible thing and very hard to measure.  

MISRA rules make some sense but are not always applicable to current coding practice.  I understand where they are coming from but you have to think about them intelligently and understand the context of what they were meant to accomplish or prevent.

IMO, good software quality is more a function of the thought process of the person who writes the code.  Things that lead to reliable code are:

1)  Understanding the problem you have.   Most code to solve a problem is written for the first time (after all, who would write it again if it works the first time?) and the problem is not always 100% completely understood when you start.  You learn the nuances as you go along.  Knowing those at the start tends to avoid strange approaches to solving problems.

2)  Having a structured mind and applying it to a problem.  Some people can do it, some can't.  You have to always think about the code as a communication to the next person who comes along and teaching them how to think about the problem you are solving with the code you use.  It's called empathy, and many coders don't have it.  Or don't take the time to use it.

3)  Knowing your language well.  Many coders take the opportunity to apply every possible technique to every project, even if it isn't helpful.  C++ Templates or exceptions are useful for certain things but you don't use them in every source file, just like you don't put every ingredient in your kitchen into the same cake.  Knowing how and when to apply your tools is important.

4)  Comments and layout are important.  Really.  For the most part, coders are lazy.  They try to pack as many characters into as small of a space as possible and press as few keys as possible to do that.  This is not helpful.  Good code tends to do things in discrete chunks (some loop to do something, or some initializations, etc).  I like to add blank lines and comments to define certain areas where a task is being performed.  It makes you structure your thoughts as to what you are doing and how to describe it, which tends to give good results for quality.

It is really hard to write quality software.  when you say "achieve a specific quality level" then you are assuming there are multiple discrete levels and they have been defined.   It doesn't work that way.   You can still use every guideline or standard in the book and end up with an unintelligible mess.