Implementing FRAM in Flight Controller Architecture

When we design custom hardware for Drone Racing or complex autonomous missions, we often focus heavily on the MCU processing power and the gyro update rates. However, there is a silent workhorse on the board that dictates how fast and reliably we can save critical flight data: the non-volatile memory.

Today, we are going to explore why traditional EEPROM is becoming a bottleneck and how implementing FRAM (Ferroelectric RAM) in my Flight Controller schematic ensures lightning-fast, bulletproof data storage.

The Bottleneck: Why Not EEPROM?

image.png

For years, flight controllers used standard EEPROM chips to save PID settings, calibration data, and waypoint missions. While EEPROM is cheap and widely available, it has a major flaw: write speed. Writing data to an EEPROM requires a physical charge pump mechanism inside the silicon, which introduces a delay of several milliseconds per write cycle.

If you are flying a high-speed drone and need to log blackbox data or save parameters on the fly, an EEPROM simply cannot keep up. Furthermore, EEPROMs typically wear out after 100,000 write cycles. In a heavily tested Flight Controller, you can hit that wear-out limit faster than you think.

If you want to understand the deep theory of how traditional memory limitations affect embedded systems, you can check on this paper: https://www.researchgate.net/figure/a-Floating-gate-non-volatile-memory-structure-b-NC-non-volatile-memory-structure_fig2_250308372. They have great articles breaking down the physics behind flash and EEPROM wear-out.

image.png

The FRAM Advantage: FM25V02A-GTR

image.png

  • <input disabled type="checkbox"> Enter FRAM. Unlike EEPROM, FRAM uses a ferroelectric film to store data. This means it writes data almost instantly as fast as the SPI bus can clock it in.

image.png

For my Flight Controller, I specifically chose the FM25V02A-GTR, a 256-Kbit F-RAM chip. According to its datasheet, this chip supports NoDelay writes and an astonishing high-endurance of 100 trillion read/write cycles. It is practically infinite for our use case. Furthermore, it operates incredibly fast, supporting SPI clock frequencies up to 34 MHz.

image.png

Take a look at the FM25V02A datasheet. Capture a screenshot of the "Features" section on page 1. This images shown highlights the "NoDelay Writes" and "100-Trillion Read/Write Cycles" bullet points.

Drop a comment if you want me to do a deeper dive into the physics of ferroelectric crystals and how they hold logic states without power!

Wiring the High-Speed SPI Bus

Integrating the FM25V02A into the Flight Controller is straightforward but requires clean, precise PCB routing. Because this FRAM operates at up to 34 MHz, we connect it directly to the fast SPI bus of our MCU.

This images shown the exact routing and support components required for the FM25V02A to function stably.

image.png

In my schematic, the FM25V02A chip is connected via the four standard SPI lines: MOSI, MISO, SCK, and M_CS_FRAM (Chip Select). However, there is a lot more going on to ensure stability:

  1. Clean Power: To ensure signal integrity during rapid, high-frequency read/write operations, I placed a 100nF decoupling capacitor (C20) right next to the VDD pin (pin 8) operating at 3.3V.
  2. State Protection: You will notice three 10kOhm resistors (R23, R24, and R25). R25 pulls the Chip Select line high to 3.3V to prevent the FRAM from accidentally activating during the MCU's boot sequence.
  3. Hardware Locking: I also used 10kOhm resistors to pull the WP (Write Protect) on pin 3 and HOLD on pin 7 high to 3.3V. By pulling these high, we tell the chip to always allow writes and never pause communication, ensuring the data stream from the flight controller is never bottlenecked.

Software Integration

Hardware is useless without the right software. When compiling firmware, we must define the storage chip so the MCU knows exactly how to talk to it.

In ArduPilot, FRAM is highly favored for saving parameters and waypoints because the instant write-speed prevents the main flight loop from locking up or hesitating during a write operation. You configure the hardware definitions (hwdef) to map the exact SPI bus and Chip Select pin to the internal FRAM driver.

You can check on this website for the exact ArduPilot developer documentation regarding memory mapping: ArduPilot Storage Allocation.

image.png

Embedded Systems2
Designing Dual-Battery Redundancy for High-Reliability Flight Controllers

Hello everyone! Welcome back to another deep dive into my Flight Controller architecture. When we design custom hardware for critical missions or expensive payload-carrying drones, relying on a single power source is a massive risk. A single failed BEC (Battery Eliminator Circuit) or a loose wire can turn a high-tech machine into a falling brick.

Today, we are going to explore the concept of Dual-Battery Redundancy, breaking down the exact components I selected in my Flight Controller schematic to ensure the main MCU never loses power.

The Problem: Single Point of Failure

In a standard setup, your flight controller receives a stable 5V from a single Power Module. The physical connection is usually made via a JST connector. For my design, I selected the SM06B-SRSS-TB(LF)(SN), which is a highly reliable 6-pin SMD connector. It provides a secure locking mechanism that resists the intense high-frequency vibrations of Drone Racing.

But what happens if the regulator supplying that connector overheats and shuts down? The MCU instantly reboots. Mid-air reboots are unrecoverable.

To solve this, professional-grade systems use a concept called "Power OR-ing." This means we provide two separate 5V inputs (Primary and Backup). If the primary fails, the backup takes over instantaneously.

Schottky vs. Ideal Diodes

To safely connect two power supplies together, we need one-way valves so that current doesn't flow backwards from one battery into the other.

1. The Classic Approach: SS34 Schottky Diode

The traditional way to create a redundant supply is using a Schottky diode like the SS34. This diode can handle up to 3A and 40V, making it incredibly robust for raw battery voltage inputs. However, physics has a cost. The SS34 has a typical forward voltage drop of around 0.5V. If your BEC supplies exactly 5.0V, the components downstream will only receive 4.5V.

image.png

This Figure shown the "Typical Forward Characteristics" graph from the SS34 datasheet. This shown exactly how much voltage you lose depending on the current draw!

2. The Modern Approach: MAX40200 Ideal Diode

For the critical 5V logic lines where every millivolt matters, I implemented the MAX40200AUK+T. This is an "Ideal Diode." It is not a standard diode, but rather a specialized IC that controls an internal MOSFET.

The result? It acts like a one-way valve but with an ultra-low voltage drop of just 43mV at 500mA! This ensures the MCU gets a clean, full 5V supply without the thermal waste of a traditional diode.

image.png

To ensure this transition between power supplies is smooth and free of voltage spikes, I placed 10uF and 100nF decoupling capacitors as close to the IC output pins as possible.

If you want to understand the deep theory behind combining power supplies and the advantages of Ideal Diodes over Schottkys, you can check on this website: Texas Instruments Application Note on Basics of Power OR-ing.

image.png

Drop a comment below if you want me to do a dedicated tutorial comparing the thermal dissipation of the SS34 versus the MAX40200 under a heavy 2A load!

Software Integration: Monitoring the Backup via PA4

Having redundant power is great, but your Flight Controller also needs to know if the primary battery has failed so you can land immediately.

To do this, we must route the raw voltage into the ADC (Analog-to-Digital Converter) of our MCU. In my schematic, I use a precise 10kOhm sampling resistor to step down the voltage safely, feeding directly into MCU pin PA4.

image.png

Firmware like ArduPilot actively reads the analog value on pin PA4. If the primary power source drops below a safe threshold, the software can trigger an RTL (Return to Launch) failsafe, saving your drone while it runs safely on the backup power routed through our MAX40200.

image.png

To show how this looks in software, This a screenshot from the ArduPilot wiki, specifically the "Power Module Configuration" page: ArduPilot Dual Battery Setup. You can also see in this discuss VTOL Plane 4+1, Dual Battery setup - ArduPlane / VTOL Plane - ArduPilot Discourse

Conclusion

Integrating dual-battery inputs using a combination of rugged SS34 diodes for high voltage and highly efficient MAX40200 ideal diodes for logic voltage adds a critical layer of safety to your Flight Controller. By adding proper 10uF and 100nF filtering and routing the voltage divider to PA4, we create a complete hardware-software safety net.

Embedded Systems2
Deep Dive into On-Board Heater Circuits

Hello everyone! Welcome back to another deep dive into my Flight Controller architecture. When designing hardware for high-performance Drone Racing, we often obsess over MCU clock speeds or gyro update rates. But there is a hidden enemy to stable flight that many designers overlook: Temperature changes.

Today, I am going to walk you through the On-Board Heater Circuit in my schematic, explaining why it exists, how the hardware works, and how the software controls it.

The Invisible Enemy: Thermal Drift

Inside your flight controller's IMU (Inertial Measurement Unit), there are microscopic mechanical structures. As your drone flies, the ambient temperature changes. As the temperature of the silicon changes, these microscopic structures expand or contract, causing the zero-point of your gyro and accelerometer to shift. This is called Thermal Drift.

For the my Flight Controller, I am utilizing high-end IMUs like the ICM-42688-P and the industrial-grade IIM-42652. If you look at the ICM-42688-P datasheet on the Gyroscope Specifications table, you will see that the Gyro Offset Temp Stability is +/- 5 mdps/C. Meanwhile, the IIM-42652 datasheet specifies a wide operating range of -40C to +105C with exceptional temperature stability.

This Figure shown the Gyroscope Specification table from ICM-42688-P to show you the exact "Gyro Offset Temp Stability" row

image.png

For the IIM-42652, this image shown on page 11 highlights its robust temperature rating (+105 deg C)

image.png

If your flight controller thinks it is rotating just because the IMU got colder, your drone will drift in the air, ruining your racing line.

HEATER Circuit

To solve this, we artificially heat the IMUs to a constant temperature (usually around 45C to 60C) so that the silicon never experiences temperature swings.

image.png

Here is the "HEATER 5V" section from my Flight Controller schematic. This image shows the MOSFET and the resistor array highlighted).

1. The Heating Elements

To generate heat, I am using standard SMD resistors. When current passes through a resistor, it dissipates power as heat (P = I^2 x R). By placing multiple resistors closely grouped around the ICM-42688-P and IIM-42652 on the PCB, we create a thermal footprint.

2. The Switching Mechanism (MOSFET)

We cannot just hook the resistors directly to the 5V line, or they would heat up continuously. We need a switch. In my schematic, I use an N-Channel MOSFET.

The Gate of this MOSFET is connected to a PWM-capable pin on the Main MCU. When the MCU applies a HIGH signal, the MOSFET turns on, allowing current to flow from the 5V rail, through the resistors, and into GND.

If you want a great refresher on how MOSFETs act as solid-state switches in circuits like this, you can check on this website: SparkFun's Tutorial on Transistors. They have a fantastic interactive diagram in the "Applications: Switches" section.

image.png

Drop a comment below if you want me to do a separate post on how to calculate the exact power dissipation and choose the right wattage rating for your SMD heating resistors!

PID Temperature Control

Hardware is only half the battle. How does the flight controller know when to turn the heater on? Both the ICM-42688-P and IIM-42652 have internal temperature sensors. The MCU reads this temperature via the SPI bus. Firmware like ArduPilot or Betaflight takes this temperature reading and feeds it into a dedicated PID loop specifically for the heater.

If the IMU is too cold, the MCU increases the PWM duty cycle to the MOSFET Gate, pushing more current through the resistors. If the IMU reaches the target, the MCU lowers the PWM duty cycle.

image.png

This Image shown the target temperature configuration parameters directly from Ardupilot IMU Temperature Calibration. This image shows exactly what the user sees when configuring the heater.

Conclusion

By integrating a simple N-Channel MOSFET and a few strategically placed resistors, the flight controller actively fights thermal drift at the hardware level. This ensures that the data from our ICM-42688-P and IIM-42652 is rock-solid.

Embedded Systems2
Ground Bounce and Power Plane Noise: Minimizing PDN Impedance

Ground bounce may appear to be harmless; however, if a logic level has ground bounce, it will misbehave.

Ground bounce results from multiple outputs being switched off or on at the same time and then causing a current surge through the package and return paths of the PCB.

When this occurs, the ground reference at that point will temporarily move, which may lead to false switch and timing errors. In addition, power plane noise adds to the problem by causing the Power Distribution Network (PDN) to perform in a less supportive manner (i.e., as a source of instability).

The root issue is the impedance of the PDN. In other words, the impedance at high speed should not only be "low resistance" but should also be "low impedance" for all frequency ranges. Once the impedance spikes, the voltage fluctuation increases and then results in a direct noise feed into your ICs.

image.png

Minimizing PND impedance; PCB top view

image.png

Minimizing PND impedance; PCB side view

Decoupling capacitors are the first line of defence. They should be placed as close as possible to the power pins on the device and should include at least two different values (e.g., 0.1 µF and 1.0µF) to provide decoupling for multiple frequency ranges. The small capacitors will decouple high frequency noise and the larger capacitors will provide decoupling for low frequency noise. The leads to the decoupling capacitors should be as short as possible and should use a wide trace or plane to provide a low inductance connection.

Ensure there are good, continuous power and ground planes. Avoid using splits in the power or ground planes underneath high speed signal lines, since this will interrupt the return path and increase ground bounce. Use a thin dielectric material between the power and ground planes to increase capacitance between the two, allowing for noise reduction.

Using multiple vias for power and ground connections will reduce inductive effects that can create bottlenecks. At higher frequencies, the single via will provide additional inductance that contributes to signal degradation.

Simulating your PDN prior to fabrication with specialized software will identify impedance peaks and provide proper capacitor placement as a starting point.

Ground is not a perfect ground; always treat the ground as a dynamic reference with appropriate design considerations.

image.png

High PND impedance PCB structure

Minimizing PDN impedance is not as exciting; however, it is a necessity. Get it right, and your board will remain stable. If you get it wrong, No amount of routing will save you!

PCB
CAN Bus (Part 2)

This is my schematic version, using TJA1051T

8730118926138011648

8730118926180089856

For a deep dive into why this resistance matters, check out this video on YouTube: https://youtu.be/fVy_EXkMKMg

DroneCAN: The Software Layer

Hardware is only half the battle. To make everything talk nicely, we use DroneCAN (formerly UAVCAN). It is an open-source, decentralized protocol that allows your FC to manage multiple nodes without the CPU overhead of a master-slave relationship.

Drop a comment if you want to see the specific C++ code I use to initialize the CAN peripheral on an STM32. it's a bit more involved than a standard UART setup!

Practical Implementation Tips

  1. Twisted Pairs: You should always twist your CANH and CANL wires together. This ensures that any noise that hits the wire hits both lines identically. I recommend at least 30 twists per meter.
  2. Cable Routing: Never run CAN wires perfectly parallel to your high-current battery leads. Cross them at 90-degree angles if you must.

Help Me Help You: The Layout File

To give you a truly high-quality review of your EMI performance, I need you to export your PCB Layout file (the .json or Gerber files from EasyEDA) and send it to me. While the schematic looks great, the Layout is where the "Silent Power Rails" and "CAN Integrity" live or die. If I can see your trace routing, I can give you a "Pro" checklist on:

  • Ground plane separation for the LIS3MDL.
  • Differential pair routing for your CAN lines.
  • Placement of your 22uF and 10kOhm components relative to high-speed lines.

Are you planning to run your LIS3MDL compass via the on-board I2C, or are you moving it to an external CAN node to get it further away from the motor interference?

DroneRacing
CAN Bus (Part 1)

Why CAN? (The Differential Advantage)

In many DIY builds, I2C is the default because it’s easy. However, I2C was designed for "chip-to-chip" communication on a single PCB, not for running wires across a drone frame. On a drone, long wires act like antennas, picking up massive electromagnetic interference (EMI) from your motors.
CAN (Controller Area Network) is different. It uses Differential Signaling. Instead of one signal wire, it uses two: CAN High (CANH) and CAN Low (CANL). The receiver only cares about the difference between them. If noise hits the wire, it usually hits both equally, and the difference remains the same.

CAN allows for four different message types. They are the data frame, remote frame, overload frame, and error frame. A standard CAN data frame makes use of the identifier, the data, and data length code, the cyclic redundancy check, and the acknowledgment bits. Both the RTR and IDE bits are dominant in data frames. If the recessive acknowledge bit at the receiving end is overwritten by a dominant bit, both the transmitter and receiver recognize this as a successful transmission.

A CAN remote frame looks similar to a data frame except for the fact that it does not contain any data. It is sent with the RTR bit in a recessive state; this indicates that it is a remote frame. Remote frames are used to request data from a node. When a node detects an error in a message on the CAN bus, it transmits an error frame. This results in all other nodes sending an error frame. Following this, the node where the error occurred retransmits the message. The overload frame works similarly but is used when a node is receiving frames faster than it can process them. This frame provides a time buffer so the node can catch up.

8730098139515379712

That figure shows a simplified version of a CAN transceiver's output and input. The '101' bitstream is coming from/going to a CAN controller and/or microcontroller. Notice that when the controller sends a stream of bits, these are complemented and placed on the CANH line. The CANL line is always the complement of CANH. For arbitration to work, a CAN device must monitor both what it is sending and what is currently on the bus, i.e., what it's receiving.

8730100183995850752

The figureshows both the CANH and CANL signals simultaneously so that you can see the CAN bus in action. Plotted below the bus signals is the differential voltage that corresponds to the dominant and recessive states of the CAN signals. The first three segments in time, t1–t3, are drawn to match up with the three bits shown above in Figure 5. We will look at this from the perspective of the output driver. The driver's input initially sees a '1' and complements this to a zero, which is placed on CANH. CANL sees the complement of CANH and goes high. This is shown as t1 in Figure 6. Notice that the CANH and CANL voltages are offset from one another. During time t1, CANH – CANL is very close to zero, since CANH and CANL are almost the same voltage. This period, where the driver is sending a logic '1' resulting in CANH and CANL being close to the same voltage, is what we call the CAN recessive state.

The next bit sent is a '0'. CANH gets its complement and CANL again gets the complement of CANH. Notice this time that the CANH and CANL voltages are not close to one another. Therefore, the differential voltage (VDIFF) is larger. This is the CAN dominant state. We say that the logic is inverted because a '1' takes the bus low and a '0' brings it high. The input receiver works in a similar fashion.

You can see the visual explanation of this noise rejection on the All About Circuits website in their Introduction to CAN Bus https://www.allaboutcircuits.com/technical-articles/introduction-to-can-controller-area-network/.

Drop a comment if you have ever had a "frozen" I2C bus mid-flight. it’s usually because of the noise.

The Hardware: Transceivers and Termination

Looking at your schematic, I see we’ve moved beyond simple logic levels. Your STM32 can't talk to the CAN bus directly; it needs a "translator" called a Transceiver.

The SN65HVD230 Transceiver

8730113464139587584

This chip converts the 3.3V digital signals from your MCU into the differential voltages required for the bus.

  • Check the Datasheet: You should download the SN65HVD230 datasheet from Texas Instruments.

This diagram illustrates the typical application circuit from Reddit https://www.reddit.com/r/PrintedCircuitBoard/comments/jcgqch/sn65hvd230_can_transceiver_breakout/?rdt=61456

The 120Ohm Termination Rule

High-speed signals on a bus can "reflect" back when they hit the end of the wire, like a wave hitting a wall. This causes data corruption.

  • The Fix: You MUST place a 120Ohm (2 x 60Ohm) resistor at the two physical ends of your bus.
  • In your FC: I noticed your design includes a termination header. This is perfect.
DroneRacing
The AMS1117, is it Good Enough for Your Flight Controller?

In my journey building flight controllers, I have seen many designers default to the AMS1117. While it is a "workhorse" for basic digital projects, using it to power a precision flight controller is like putting a noisy lawnmower engine into a luxury car.

1775570284679236388397022368995.jpg

If you want your EKF to be stable and your sensor to be accurate, you need a "Silent" power rail. Here is how I explain the shift from basic regulation to professional power integrity.

The AMS1117 Problem: Why it is "Dirty"

17755702253204081620965438544182.jpg

The AMS1117 is a linear regulator, but it is not a "Low-Noise" regulator. For a drone engineer, it has three major flaws:

  • High Dropout Voltage: It usually requires about 1.1V to 1.3V of "headroom." If your battery drops, your 5V rail might dip, causing your 3.3V sensor rail to brown out.
  • Poor PSRR: Power Supply Rejection Ratio (PSRR) measures how well the LDO blocks noise from the input (like ESC switching noise). The AMS1117 has a low PSRR at high frequencies where motors operate.
  • High Output Noise: It generates its own internal electrical "hiss" which can confuse the sensitive ADCs in your IMU.

Ultra-Low Noise LDOs

When I design a professional FC, I look for LDOs specifically marketed as Ultra-Low Noise or High PSRR. Examples the LP5907 or MIC5219.

You should look for:

  1. PSRR (dB): Look for values above 60dB or 70dB at 10kHz. This tells you the LDO is an active filter against motor noise.
  2. Noise (uVRMS): A silent LDO should have an output noise below 10uVRMS (from 10Hz to 100kHz).
  3. Accuracy: Look for 1% or 2% output voltage accuracy to ensure your sensors always see exactly 3.3V.

This images shown the PSRR vs. Frequency graph in an LDO datasheet. This curve illustrates how effectively the regulator blocks noise at different motor RPM frequencies.

8729859416052142080

Designing the "Silent" Rail Architecture

An LDO alone is not enough. You must build a Pi-Filter (C-L-C) to protect your sensors.

17755710369981065171610928000100.png

Here is the standard implementation I use for the 3.3V rail. The Component Recipe:

  • Input Bulk Capacitor:22uF tantalum or high-quality ceramic. This handles the "big" ripples from the main battery.
  • The Ferrite Bead: Use a 10uH or 600Ohm (at 100MHz) ferrite bead between the LDO and the sensor. This acts as a wall against high-frequency RF noise.
  • Output Decoupling: Use a combination of 10uF (for stability) and 100nF (for high-frequency spikes).

Layout

In my experience, the schematic is only 50% of the work. The other 50% is the PCB Layout.

  • Ground Planes: Use a solid Ground Plane. Do not "snake" your ground traces.
  • Kelvin Sensing: Place your output capacitors as close as humanly possible to the Vdd pins of your IMU and Compass.
  • Isolation: Keep the noisy AMS1117 (if used for LEDs or non-critical parts) on a completely different side of the board from your sensor LDO.

VFLGA-12 package outline and pin indicators to assist in correct PCB footprint design.

8729862722698539008

Recommended Resources

Professional Websites

Journals and Papers

  • "Power Supply Noise Reduction in Sensor Systems": Search this on** IEEE Xplore**. It explains why high-frequency noise causes "bias instability" in gyroscopes.
  • "System-on-Chip (SoC) Power Integrity": While advanced, this journal content explains the importance of decoupling capacitors like the 22uF and 100nF combo I mentioned.
DroneRacing