Direct Flashing vs Indirect Flashing through MPU/MCU

In-system programming (ISP) is a critical technique that allows devices — microcontrollers (MCUs), memories, CPLDs and others — to be programmed without physically removing the components from the circuit board. It simplifies both development and manufacturing, because devices can be programmed, updated and configured while already installed in the system.

There are two primary methods for implementing in-system programming:

• Direct in-system programming (direct flashing)
• In-system programming via an MCU or microprocessor (MPU)

The choice between them depends largely on the project’s specific requirements, the overall cost, performance expectations and the complexity of the hardware design. Each method offers distinct advantages and trade-offs.

Direct in-system programming

Direct in-system programming, also known as direct flashing, is the most common approach for programming memory devices embedded on a circuit board. The target device is programmed straight through a dedicated debugging interface such as UART, SPI, I2C, JTAG or SWD (Serial Wire Debug). These interfaces let a programming system load firmware directly into the device’s memory. The flashing process can be performed in one of two main ways:

• Direct flashing via debug interface: the firmware is transmitted through the debug interface into the target device’s memory. This method is relatively straightforward and is typically used when the target device has the necessary interfaces for direct communication.
• Indirect flashing via an application in RAM: the programming system loads an application into the target device’s RAM. Once executed, that application carries out the flashing process by communicating with the programming system through the debug interface. RAM serves as temporary storage for the executable code, allowing the programming system to transfer firmware to the device’s non-volatile memories.

Advantages of direct in-system programming

• Simplicity: it is often simpler to implement, because it leverages standard debug interfaces directly.
• Speed: flashing through dedicated interfaces tends to be faster and more efficient, especially with high-speed protocols such as JTAG/SWD or SPI.
• Widely supported: many MCUs and programmable devices ship with built-in support for direct programming through these common debug interfaces, making it a broadly accepted and accessible solution.

Disadvantages of direct in-system programming

• Limited flexibility in complex systems: where multiple devices are present, some debug interfaces may not be available or accessible. The method may then not be feasible at all, or not without additional hardware intervention.

In-system programming via MCU/MPU

In contrast to direct flashing, in-system programming via an MCU or MPU uses an intermediary microcontroller or microprocessor to program the target device. This is the approach when the target cannot be programmed directly through a debug interface, or when the system design does not provide access to such interfaces.

Here the target device is connected to a peripheral of the MCU/MPU, such as QSPI or specific GPIO pins. When the programming environment does not allow direct access to the target’s debug interface, the MCU/MPU’s own debug interface (JTAG, USB and so on) is used to load an application into the intermediary’s RAM. Once loaded and executed, that application takes control of the system’s peripherals by configuring and initialising them, and communicates with the programming system through the debug interface to flash the target device connected to it.

Advantages of in-system programming via MCU/MPU

• Greater flexibility: particularly valuable in complex systems where the target device has no direct debugging interface, or where additional control over peripheral interfaces is needed.

Disadvantages of in-system programming via MCU/MPU

• Increased complexity: the system design becomes more complex, since additional software is required to control the flashing process.
• Slower flashing speed: the process may be slower than direct programming, because it depends on the performance of the intermediary MCU/MPU rather than on the target’s own debug interface.

Choosing between the two

The decision depends on several factors:

1. Project requirements. If the target device has accessible debug interfaces and flashing needs to be fast and simple, direct flashing is preferable. If the system is more complex, or the target lacks a debug interface, flashing via MCU/MPU becomes necessary.
2. Cost and hardware design. Direct flashing typically requires fewer resources and simpler software. Flashing via MCU/MPU adds software complexity and can increase costs.
3. Performance needs. Direct flashing offers faster programming times, making it ideal for mass production or high-performance applications. Flashing via MCU/MPU, while more flexible, may be slower and carries additional overhead.
4. System complexity. For simpler systems with a limited number of devices, direct flashing is usually sufficient. For larger, multi-device systems, or those needing specialised control over peripheral interfaces, flashing through an MCU/MPU is often the better choice.

Conclusion

Both direct in-system programming and in-system programming via MCU/MPU have their strengths, and each suits a different type of project. Direct flashing is generally preferred for its simplicity and speed when direct debug interfaces are available. Flashing through an intermediary MCU/MPU is advantageous when more flexibility is needed — in complex systems, or where the target device lacks a direct programming interface. The right choice depends on the specific needs of the project, including hardware design complexity, performance requirements and cost considerations.