Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/analogdevicesinc/codefusion-studio/llms.txt

Use this file to discover all available pages before exploring further.

The Generate Code feature translates every configuration choice made in the System Planner — peripheral assignments, pin multiplexing, clock settings, and memory partitions — into ready-to-build C source files that are added directly to your project. Once generated, the files are detected and compiled by the build system automatically, and the start-up code invokes the generated initialization functions so you do not need to call them manually. This page explains what code generation produces, how to trigger it from the IDE or the command line, and what you can safely modify versus what will be overwritten on the next generation.

What code generation produces

Code generation creates source files that configure every system resource you have set up in the System Planner:
  • Pin initialization — Sets the multiplexing and function configuration for every assigned pin.
  • Clock initialization — Applies the clock tree settings including source selection, dividers, and multiplexers.
  • Peripheral initialization — Configures each allocated peripheral according to the settings captured in the Peripheral Allocation and Pin Config tabs.
  • Memory layout — Produces linker-script fragments or devicetree nodes (depending on the firmware platform) that reflect the memory partitions you defined.
  • AI model files — If the workspace includes AI model configurations, the corresponding TFLite Micro (src/adi_tflm) or CNN (src/adi_cnn) source directories are generated alongside the system configuration.
The exact files, directory structure, and file format are defined by the code generation plugin selected for each core. Zephyr projects produce devicetree overlay and KConfig fragments; MSDK projects produce C source and header files.

Prerequisites

Before generating code, verify the following:
1

Resolve configuration errors

Ensure you have resolved any configuration errors visible in the System Planner, such as pin multiplexing conflicts (shown as red circles in the Pin Config tab) or out-of-range clock frequencies (shown as red nodes in the Clock Config tab). The Workspace Projects table at the bottom of the dashboard surfaces any detected issues with an error indicator.
2

Review the Generate AI Models option

On the Generate Code tab, check the Generate AI Models option to confirm which AI model files will be regenerated for each core.
3

Back up manually modified files

Be aware that generated files overwrite any existing versions on disk. If you have made manual edits to previously generated files that you want to keep, back them up before running generation.
Generated files will overwrite any existing versions. Back up any manually modified generated files before regenerating to avoid losing your changes.

Generate code from the System Planner

1

Open the Generate Code tab

In the System Planner dashboard, click the Generate Code tab.
2

Select cores

Select the cores you want to generate code for. You can generate for all cores at once or for individual cores independently.
3

Click Generate

Click Generate to start the code generation process.
4

Save configuration if prompted

If you have unsaved changes, you will be prompted to save the .cfsconfig file before generation proceeds.
5

Review generated files

The generated files are saved to your project or workspace according to the selected plugin’s configuration. Check the File Explorer — the new files appear automatically and are ready to build.
The generated code files are added to your project automatically and are detected and built without requiring any additional configuration changes to your build system. The start-up code handles invoking the generated initialization functions.

Generate code from the CLI

The cfsutil generate command lets you trigger code generation from the command line — useful for CI pipelines, scripted builds, and headless environments.
cfsutil generate -i <path-to-.cfsconfig> -o <output-directory>

Command flags

FlagDescription
-i, --input(Required) Path to the .cfsconfig file.
-o, --outputOutput directory for generated code. Defaults to . (current directory).
-s, --search-pathAdditional search path for plugins and data models. Can be specified multiple times.
-v, --verboseDisplay full paths for all generated files.

Examples

Generate code using a config file and write output to a specific directory:
cfsutil generate -i ./myProject/.cfsconfig -o ./myProject/src/generated
Generate with verbose output to see every file path written to disk:
cfsutil generate -i ./myProject/.cfsconfig -o ./myProject/src/generated --verbose
Use an additional plugin search path for custom code generation plugins:
cfsutil generate -i ./myProject/.cfsconfig -o ./output -s /path/to/custom/plugins

How plugins define code generation

Code generation is not built into the CFS core — it is entirely defined by the code generation plugin selected for each core in the workspace. The plugin’s codegen section specifies the templates and logic used to produce source files from the System Planner configuration. When CFS generates code, it:
  1. Reads the current .cfsconfig file for pin, clock, peripheral, and memory settings.
  2. Selects the appropriate code generation plugin for each core.
  3. Passes the configuration data to the plugin’s generate-code hook.
  4. The hook returns a map of filenames to arrays of generated lines, which CFS writes to disk.
This architecture means that adding a new firmware platform (such as a custom RTOS or HAL) only requires building a new plugin — the rest of the CFS toolchain remains unchanged.

Regenerating after configuration changes

Whenever you modify your system configuration in the System Planner — adding a peripheral, reassigning a pin, adjusting a clock divider, or resizing a memory partition — you should regenerate code to keep the generated files in sync with the configuration.
Make configuration changes in the System Planner first, then regenerate. This keeps the .cfsconfig file as the single source of truth and avoids manual synchronization between configuration and code.

What is safe to edit manually

The following areas of your project are not touched by code generation and are safe to modify at any time:
  • Your application source code (any file you created that is not a generated file).
  • CMakeLists.txt additions and overlay files you maintain independently.
  • Zephyr prj.conf KConfig fragments that are not generated from the plugin.
  • Any directory or file that the selected plugin does not define as an output target.

Troubleshooting

Open the System Planner and check the Workspace Projects table for error indicators. Common causes include unresolved pin conflicts, out-of-range clock frequencies, and overlapping memory partitions. Resolve all errors shown in red before attempting to generate again.
Generated files are added to the project according to the plugin’s output path configuration. If files are not being compiled, verify that the output directory specified in the Generate Code tab matches the source path expected by your build system. For Zephyr projects, ensure the devicetree overlay path is included in your board configuration.
The CLI requires access to the same plugins used by the IDE. Use the -s flag to specify additional plugin search paths, or ensure the plugins are installed in the default CFS plugin directories. Run cfsutil cfsplugins list to see which plugins are currently visible to the CLI.

Build docs developers (and LLMs) love