Uploader and Bootloader

The Neuro N6 is programmed over USB through a custom DFU bootloader built into the first stage bootloader (FSBL). The host side is a set of Python tools under tools/neuro-n6-uploader in the core, which the Arduino IDE invokes on Upload and which can be run directly.

#Deploy sequence

The IDE runs neuron6_deploy.py with the signed binary, the upload address and the model manifest the build produced. The script:

1. Enters the bootloader once, by the 1200 baud touch or by finding a board already in the bootloader.
2. Uploads each model weight blob listed in the manifest to its flash address, skipping blobs whose checksum the bootloader reports as already matching, unless Tools > Model weights is set to always upload.
3. Uploads the WiFi module firmware to 0x91E00000 if the sketch links a wireless library, under the same skip rule.
4. Uploads the application to 0x90100000, verifies it and reboots into it.

Sketches without models behave as a single-binary upload.

#USB identities

Distinct identities for the application and the bootloader allow the host to know which it is talking to. The application's USB descriptor also carries a per-chip serial number from the STM32N6's 96-bit unique ID.

The bootloader is maintained in the Neuro-N6-Bootloader repository and is programmed once per board with an ST-LINK.

#Entering the bootloader

Every route sets a FORCEDFU flag in one of the STM32N6's 32 backup registers, which are retained across a reset, and resets. The FSBL reads the flag and enters its DFU loop instead of booting the application. The OTA library uses further backup registers to pass checksums from the bootloader to the application.

• Opening the serial port at 1200 baud and dropping DTR. The IDE does this on Upload.
• The character b on the CDC port, with Tools > Debug console On.
• The Reboot to Bootloader button in the GUI uploader.
• A double press of the reset button, less than 900 ms apart, which does not require a running application. The RGB LED pulses red in bootloader mode.

#Other boot modes

The STM32N6 has no internal flash and always starts in its boot ROM, which selects a boot mode from the BOOT0 and BOOT1 pins, an OTP word and a backup register, and authenticates the first stage image it loads. BOOT0 is a dedicated pin latched at reset release; BOOT1 is a configurable pin. Both are on the six-pin debug connector. In external flash boot, the default, the ROM loads the FSBL from the XSPI flash. Serial boot (BOOT0) loads an image over USB or UART and is not supported by Ohm Lab tooling. Development boot (BOOT1) reopens debug access and idles, allowing debugging in STM32CubeIDE and programming the external flash with STM32CubeProgrammer through the board's external memory loader; it is the route for recovering a board whose FSBL has been corrupted or erased. The FSBL occupies 0x90000000 to 0x90100000 and is not overwritten when programming flash this way.

#Command line

python neuro-n6-uploader-cli.py --port COM7 --bin firmware_Trusted.bin --address 0x90100000

The tool flashes immediately if the bootloader is present. Otherwise it reboots the application, locating it by USB identity so the --port value need not match the current COM number, waits for the application port to disappear and the bootloader to appear, and flashes. --no-reboot skips the reboot for a board already in the bootloader.

#Graphical uploader

Neuro N6 DFU.exe under dist/ is a standalone Windows build that bundles its own Python. The workflow is Select Firmware, Reboot to Bootloader if the application is running, then Start DFU. build_exe.bat rebuilds it with PyInstaller.

#Signing

The FSBL accepts only a signed image. The build's post-build hook runs tools/sign_bin.py, which locates STM32CubeProgrammer's signing tool and produces <sketch>_Trusted.bin. The signing tool writes a fresh signature on every run, so two builds of identical source produce different _Trusted.bin files; the core's build verification tooling fingerprints the unsigned binary and the ELF for that reason.

#Python on Windows

The build hooks invoke Python through tools/run_python.cmd, which locates a working interpreter. A bare python from the IDE can resolve to the Microsoft Store stub when Python was installed through conda. The hook is invoked as cmd /c call "<path>" so that a sketchbook path containing spaces, such as a OneDrive folder, is handled.

#Over-the-air path

The N6OTA library provides a second route for the application image, staged in PSRAM and written by the bootloader into an A/B slot. See Over-the-air Updates.