Flashing firmware is the act of writing a compiled program into a device’s flash memory so it will run the next time the chip starts. Once the toolchain has produced a binary or HEX image, it still has to be transferred onto the physical part, and flashing is that final step. It is the moment software stops being a file on a developer’s computer and becomes the resident behavior of a piece of hardware.
Flash memory has a physical quirk that shapes how programming works: it must usually be erased before it can be rewritten. As the OpenOCD documentation puts it, “flash memory normally needs to be erased before it’s written,” because erasing turns a sector’s bits all to ones and writing can then only turn ones into zeroes. A programming sequence therefore typically erases the relevant sectors and then writes the new image into them. Tools expose this directly; avrdude, for instance, documents the chip-erase option that is “almost always necessary before programming the flash” on an AVR before the new contents are uploaded.
There are several routes for getting bytes onto the chip. One is a hardware debugger connected to dedicated programming and debug pins, speaking JTAG or, on ARM Cortex-M parts, the two-wire SWD protocol. OpenOCD, a widely used open-source on-chip debugger, drives such adapters and provides flash commands to erase and write the device; its documentation describes the write image command, which writes an image file to the target’s flash and notes that “only loadable sections from the image are written.” A second route is in-system programming (ISP), a simple serial interface used by AVR programmers like those avrdude supports, which can burn a HEX file straight into the chip in place.
A third route needs no external hardware at all: a resident bootloader. If the device already holds a small bootloader in a protected region, that code can receive a new application image over a serial port, USB, or a network and write it into flash itself. This is how an Arduino accepts a new sketch, and how field firmware updates reach deployed devices that no one will ever connect a programmer to. The bootloader effectively flashes the rest of the firmware on the chip’s own behalf.
Whatever the route, the same care applies because flash holds the program and any persistent data. OpenOCD’s manual warns to be careful with erase operations, since “portions of the flash outside those described in the image’s sections might be erased with no notice.” A flashing tool can also verify the result by reading the memory back and comparing it to the source image, confirming the device holds exactly what was intended before it is allowed to run.
Flashing is thus the bridge between the embedded toolchain and a working device. The cross-compiler and linker decide what the bytes are and where they belong; avrdude, OpenOCD, a programmer, or a bootloader is what actually puts them there.