If you are working with a custom system-on-chip (SOC) that uses an ARM Cortex-M0 processor, you may be wondering if you need separate flash programmer software to program the flash memory. The short answer is – it depends. There are a few factors to consider:
On-Chip Bootloader
Many SOCs with Cortex-M0 and other Cortex-M cores include an on-chip bootloader or flash programming logic. This allows programming of the internal flash memory through a debug interface like SWD without requiring external flash programming software. However, the on-chip bootloader may have limitations in terms of flash memory regions it can access or requiring the processor to be in certain modes.
External Flash Memory
If your custom SOC uses external flash memory chips rather than internal embedded flash, you will likely need external flash programmer hardware and software to program that external memory. The processor bootloader typically can’t program external flash chips. Common external flashes used with Cortex-M include SPI flashes and QSPI flashes which require external programmers.
Debug Access Port
To program flash memory through on-chip bootloader or external programmer, you need a debug interface like SWD (Serial Wire Debug). This is accessed through the Cortex-M debug access port (DAP). On custom SOCs, the DAP configuration can vary. Some provide a dedicated SWD or JTAG interface, while others require a custom interface driver. The DAP configuration affects your ability to access the processor for flash programming.
Toolchain Support
Most Cortex-M0 toolchains like GCC ARM Embedded and Keil MDK-ARM include flash programming utilities. They can program internal and external flash through a supported debug interface like SWD. Before purchasing a toolchain, verify it supports your custom SOC debug interface for flash programming. Vendor SDKs may also include flash programming tools.
Production Programming
While manual flash programming through a debug adapter works for development, production programming requires automated tools. Dedicated flash programmers are an option for high volume production. For lower volumes, you can create custom scripts leveraging tools like OpenOCD, pyOCD, and dfu-util for automated programming through USB or wireless interfaces.
Recommendations
- Check if your SOC has an on-chip bootloader that supports your flash memory regions and avoids external flash programmer need.
- For external flash, budget for programmer hardware/software unless you can leverage open source tools.
- Validate debug interface access meets your flash programming requirements.
- Compare toolchain support for flash programming before purchasing.
- Plan production programming solution upfront – dedicated programmers or custom scripts.
On-Chip Bootloader Details
Many ARM Cortex-M0 and Cortex-M4/M7 based SOCs include an on-chip bootloader in ROM or flash memory. This handles basic flash programming functions through the debug port without requiring a separate external flash programming utility.
For example, NXP Kinetis, STMicro STM32, Atmel SAMD20/SAMD21, Cypress PSoC 4000S/4100S, and Silicon Labs EFM32 series, all provide an on-chip bootloader or “system flash memory interface” for flash programming over SWD/JTAG.
Typically these bootloaders allow erasing and programming of flash memory sectors or pages while running from SRAM or ROM. This avoids needing to erase the bootloader itself during updates. Silicon Labs EFM32 even allows self-modification of the bootloader.
However, on-chip bootloaders have some limitations:
- Often can’t write to sectors 0 or 1 which contain initial bootloader code.
- May only program internal embedded flash, not external flashes.
- Requires debug access to halted core vs. application access.
- Limited configuration flexibility compared to standalone programmers.
So while internal bootloaders simplify programming, they aren’t a complete replacement for external tools in all cases.
External Flash Memory
Whereas Cortex-M0/M4 SOCs typically include internal flash memory, some custom designs may only use external flash chips. Serial NOR flash, parallel NOR flash, NAND flash, and SPI / QSPI serial flash are all possibilities.
Since these external memories are not managed by the processor’s on-chip bootloader, an external programmer tool is required to write data to them. Common options include:
- Dedicated Flash Programmers – Standalone hardware devices.
- USB Flash Programmers – Low cost USB dongles, leverage host PC.
- Software Flash Programmers – Control programming through target debug port.
For high volume production, dedicated flash programmers provide fast, parallel writes for NOR or NAND flashes. But these are expensive and overkill for lower quantities.
USB flash programmer dongles connected to a host PC provide a lower cost flexible option. Many support SPI, QSPI, and parallel NOR flash chips. Vendors include Segger, Olimex, Microchip, Tin Can Tools, and Raspberry Pi.
Software flash programmers run on the development computer and communicate through the target’s debug port. They work well for SPI and QSPI flashes. Open source options like OpenOCD have plug-ins for many flash chips. Commercial tools like IAR, Keil, and Codescape also support external flashes.
Debug Access Port (DAP)
To leverage on-chip bootloader programming or external software programming tools, you need debug port access to the Cortex-M0 processor. This is provided by the debug access port (DAP).
The DAP handles the low level debug protocol like JTAG or SWD. It presents a bridge to the processor’s internal debug module. On custom SOCs, the DAP implementation can vary:
- Dedicated JTAG / SWD pins – Requires no software driver.
- Multi-drop JTAG – Shares pins but needs driver for selecting device.
- Custom JTAG-to-SWD – Needs software driver to handle conversion.
- SPI or UART-based SWD – Requires more complex software driver.
More complex DAP interfaces require compatible debugger software drivers. For example, Keil MDK-ARM, Segger J-Link, and OpenOCD all have plugins for custom DAP implementations. Confirm toolchain and programmer support for your DAP early to avoid issues.
Toolchain Support
Toolchains for ARM Cortex-M provide debuggers, compilers, and utilities for application development. Many also include flash programming capabilities or integrate with external programming tools.
For example, ARM Keil MDK has a flash programmer utility that can erase and program Cortex-M internal flash through SWD/JTAG. Segger J-Link has a dedicated flash programming tool as well. IAR Embedded Workbench leverages its debugger to flash memory too.
GCC ARM Embedded, Linaro, and CodeSourcery toolchains can integrate with OpenOCD for flash programming. There are also CLI utilities like STM32CubeProgrammer, NXP memtool, and TI Uniflash for programming.
Before selecting a toolchain, validate that it supports programming your custom SOC flash memory regions through the available debug port. Some may require purchasing a proprietary JTAG/SWD probe for access.
Also check SDKs from your SOC vendor or FPGA partner. They may include flash programming utilities for their hardware platforms.
Production Programming
While manual flash programming through a debug adapter works for initial development, production deployment requires an automated process. There are several approaches to consider:
- Dedicated Flash Programmers – Fast parallel programming but high cost.
- Scripted Programming – Leverage pyOCD, OpenOCD, dfu-util.
- Over-the-Air (OTA) – Update flash over wireless networks.
- Microcontroller Programmers – Use a secondary low-cost MCU.
As discussed earlier, dedicated flash programmers supporting NOR and NAND memories provide very fast, production-scale programming. But these are expensive and only suited for high volume manufacturing.
For lower to medium volumes, creating custom scripts with tools like OpenOCD, pyOCD, and dfu-util allow automated programming through batch files or on a small production line.
Over-the-air (OTA) programming allows updating device flash memory wirelessly over Bluetooth, WiFi, or cellular networks. This avoids physical programming connections but requires firmware support.
Finally, a secondary low-cost microcontroller can be used as an external flash programmer. This allows adding programming functions without increasing primary MCU costs.
All these options have tradeoffs between cost, convenience, and programming time that must be evaluated for a given production environment.
Conclusion
To summarize, using a custom SOC with Cortex-M0 and external flashes will likely require external flash programming software and hardware.
An on-chip bootloader avoids this need for internal flash programming, but has limitations compared to dedicated tools. The DAP configuration also impacts available programming options.
Selecting a toolchain that integrates with your debug port and flash memory setup early on ensures compatibility. And planning an automated, production-level programming solution upfront saves issues later.
With upfront planning, using a custom SOC with Cortex-M0 flash memory can be accomplished smoothly without surprises.
