First Upload

The Blink example is the first sketch to upload. It exercises the toolchain, the signing step and the USB bootloader without involving the camera or a neural network.

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_BUILTIN, LOW);   // active low: LOW lights the LED
  delay(1000);
  digitalWrite(LED_BUILTIN, HIGH);
  delay(1000);
}

The RGB LED is common anode, so a LOW output lights it. LED_BUILTIN is the green channel.

#Build sequence

The build output shows a small number of status lines rather than compiler commands. The stages are:

1. A toolchain check confirms arm-none-eabi-gcc is present and at least GCC 11.
2. Any models named by #pragma neuron6 are compiled for the NPU. Blink has none.
3. The sketch, the core and the libraries are compiled. The core is rebuilt on every build, taking one to two minutes.
4. The binary is signed, producing <sketch>_Trusted.bin.
5. A memory summary is printed. The application image limit is 1.5 MB (see Memory Map).

Tools > Build output > Verbose expands the summary to full stage detail.

#Upload sequence

The STM32N657 has no internal flash. The application is stored in external flash and copied into RAM by a first stage bootloader (FSBL) at boot. Uploads therefore pass through a USB DFU bootloader. The uploader:

1. Opens the serial port at 1200 baud and drops DTR. The application recognises this as a request to reboot into the bootloader.
2. Waits for the bootloader to enumerate. The bootloader has a distinct USB identity, so the host can distinguish it from the application.
3. Flashes any model weights that differ from those already in flash.
4. Flashes the signed application to 0x90100000, verifies it and reboots into it.

The process takes a few seconds. On completion the LED blinks and the port reappears with the application's identity.

#USB identities

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

#Entering the bootloader

Each of the following reboots a running application into the bootloader. All set the same flag in RTC backup memory before resetting; the FSBL reads the flag and waits for a DFU session instead of booting the application.

• The IDE Upload button, through the 1200 baud touch.
• The character b on the serial port, when Tools > Debug console is On.
• The Reboot to Bootloader button in the standalone uploader.
• A double press of the reset button, with less than 900 ms between presses.

The double press is the recovery route for a board whose application has crashed and cannot respond to the 1200 baud touch. It is handled by the bootloader and does not depend on the application. The RGB LED pulses red while the bootloader is active. The uploader detects a board already in the bootloader and skips the reboot step.

#Failure modes