TinyML EON Model Updates: Identify the Compiled Inference Artifact Before Replacing a FlatBuffer

Replacing a model file does not necessarily change the graph executed by an embedded application. In an EON-compiled Edge Impulse export, the neural model can be represented by generated C++ weights and inference functions already linked into the program. A newly copied FlatBuffer is irrelevant to that path unless the application actually consumes it.

Start by identifying the model’s executable representation. This is a build-artifact question before it is a deployment-transport question. The analysis uses official Edge Impulse documentation and the moving official SDK source read on 19 October 2026; no fixed SDK commit, generated export, firmware build or inference result is claimed.

Locate the conversion boundary

The EON compiler explanation describes a FlatBuffer input and generated .cpp and .h output containing weights and functions. Graph construction and allocation planning occur during generation, leaving initialization, preparation and invocation functions for the device.

The FlatBuffer is therefore an input to this compilation stage. In the scoped compiled path, it is not automatically a replaceable runtime model file. A deployment script can successfully copy a new .tflite while the executable continues calling the functions generated from the previous model.

Ask for an artifact map with three concrete links: the model supplied to export, the generated sources supplied to the firmware build, and the binary installed on the target. A filename shared across all three is not enough. Preserve actual export identity and build inputs so the map can distinguish two generations with similar directory names.

Follow the selected inference path

The reviewed official tflite_eon.h is gated by the TFLite engine selection and EI_CLASSIFIER_COMPILED == 1. Its setup obtains an EON graph configuration and calls model_init, model_input and model_output; invocation calls model_invoke through that configuration.

Those call sites support a specific inference: replacing an unrelated serialized byte array does not retarget the linked function references. Inspect the corresponding files in the actual exported project before applying that conclusion to a product. The cited moving source is evidence of the reviewed implementation, not a promise that every historical or future export has identical symbols.

Do not flip EI_CLASSIFIER_COMPILED as a shortcut to converting an export. The alternative path needs its own compatible model artifacts, configuration and build inputs. A macro selects code; it does not generate the missing model representation or reconcile preprocessing settings.

Replace a coherent export, then rebuild the consumer

For the ordinary statically linked MCU arrangement, regenerate the desired supported export and integrate its model-related sources and metadata together. Rebuild and relink the application that owns those generated functions. The exact update unit is the binary containing the compiled graph, which should be established from the product’s build rather than inferred from a downloaded filename.

The C++ library guide describes the SDK, model-parameters and tflite-model directories and the public classifier entry points. Use the export’s supported public integration path. Hand-editing generated weights or function bodies makes it harder to establish which model and preprocessing contract the program implements.

A clean build is a useful diagnostic control, but “try cleaning” is not the core answer. First establish which generated files should change and why. Then inspect the build’s source list, selected objects and final linked artifact to determine whether those changes reached the executable.

Design a two-model identification check

Choose two deliberately distinguishable model exports and a fixed input for which their expected outputs are known from the corresponding validation environment. Preserve each export and its preprocessing metadata. On a disposable integration target, first install the application built from export A and capture its output.

Next perform the suspected ineffective operation: replace only the standalone FlatBuffer that the compiled path does not reference. Establish that the executable and its linked graph are unchanged before interpreting the result. Finally, build and install the coherent export B application and compare against B’s expected output under the same input contract.

These are proposed checks, not an experiment performed here. They isolate the representation boundary without attributing a difference to sensor noise or claiming model accuracy from one sample. If B’s generated functions are demonstrably linked yet outputs remain unexpected, continue with input and preprocessing verification. If A’s functions remain linked, changing the file-transfer mechanism cannot complete the model update.