On software design, usually the key document is the SDD, the Software Design Document, which describes in detail how the software works, as it would be finished (e.g. in present time: the system HAS..., it USES...). Since firmware is just a type of software, I assume an FDD would just be an SDD, with specific features related to the firmware.
You will find a lot of gibberish about how to structure your document. I think only on this: a system is a set of interrelated parts (Von Bertalanffy et.al.). So, you need to describe your software system in two parts: the system (statics) and the interrelations (dynamics). Google for SDD templates, and you will see that is the generic structure. So, you will have an introduction, the statics section, the dynamics section, and a conclusive part, that would consider the consequences of the design.
Do not forget that the purpose is not to deliver a document, but to actually think (and allow others thinking) in a systematic manner on the details of the implementation.
The last SDD I've written responded to a set of client requirements (yes, systems have a purpose!). Then, the document had almost this structure:
- An introduction describing the software and its context, short, an abstract. That is, what is this software? which function does it performs? for what objectives? references to documentation (or actual content, if the project is small), where what the project is about, what teams participate, their roles, etc. A person that reads this document should either know the project or either have a way to know its details. In our case, the software requirements were already defined, so references were included.
- The methodology the software design has been performed and how it is implemented. In my case, this is a research project, researches were done over the theoretical domains and that was taken to use cases, which defined the static structure of the system, components, tests, blahblah. Important to describe the tools (e.g. UML, Agile, etc.). I assume you need to include features specific to the hardware, circuits, whys and hows.
- First, what I call the static section: the system, its components (subsystems, subsub...), interfaces, structure, implementation, etc. Personally, I consider it is very important to describe in part 2. the use cases (e.g. a person pushes a button and a light is activated), which would help define the system and its subsystems (e.g. we need a button, a light diode, a battery). Tests can be considered components, in specific cases, because they act many times as reference implementations. In systems managing databases, data structures are to be included in a proper section or whole chapter, if required. In your case, you should pay attention to all static features of your system: components, specifications, alternatives, etc. Interfaces are a key element, since they determine the interactions between parts.
- Second, the dynamics section: the interactions between the parts (which determine the relations). Following the example, here you will say "the parts are connected using cables like this; since the button allows current passing, then, the current flows within cables A and B, and the LED is subject to a difference of potentials causing it to emit light, and cause the battery to drain at rate X".
- Then, feel free, according to your personal criteria, to enter into the details you consider important to clarify. In our button-battery-LED system, we could introduce the impact of having such fragile circuit exposed, so why a box encloses it; how often the button should be changed due to risk of failure, a recommendation to include a battery level meter, the economic impact (expensive, but cheap on the long term), and how would it be connected, etc.
Feel also free to look other templates and include parts you consider important, but within the structure defined previously.