This repo contains the nano firmware flasher tool. It's a .NET Core Tool that allows flashing a .NET nanoFramework target with a firmware image (nanoBooter and nanoCLR), the application deployment (all assemblies required to run a .NET application) and restore previously saved deployment images. Is part of .NET nanoFramework toolbox, along with other various tools that are required in .NET nanoFramework development, usage or repository management.

It makes use of several 3rd party tools:

• Espressif esptool You can find the esptool and licensing information on the repository here.
• STM32 Cube Programmer You can find the source, licensing information and documentation here.
• Texas Instruments Uniflash You can find the Uniflash tool and licensing information here.
• SEGGER J-Link You can find the J-Link, licensing information and documentation here.

We are also distributing this tool as a .NET library so it can be integrated in 3rd party applications. Please check the README in the Samples folder for more details along with sample applications.

Install .NET nanoFramework Firmware Flasher

Perform a one-time install of the .NET nanoFramework Firmware Flasher tool using the following .NET Core CLI command:

After a successful installation a message is displayed showing the command that's to be used to call the tool along with the version installed. Similar to the following example:

Install path issues

[!CAUTION] That are know issues running commands for STM32 devices when nanoff is installed in a path that contains diacritic characters. This is caused by a known bug in STM32 Cube Programmer. If that's the case with your user path, for example, you have to install it in a location that does have those. To accomplish that, use the following .NET Core CLI command on which the path where the tool will be installed is specified:

Note that if you're not using nanoff with STM32 devices, this limitation does not apply.

MacOS users

You'll need to add nanoff to your path as well, once installed run:

Update .NET nanoFramework Firmware Flasher

To update .NET nanoFramework Firmware Flasher tool use the following .NET Core CLI command:

If the tool was installed at a specific path, use the following .NET Core CLI command instead:

Usage

Once the tool is installed, you can call it by using its command nanoff, which is a short version of the name to ease typing.

The tool includes help for all available commands. You can see a list of all available ones by entering:

List of usage examples per platform and common options:

• ESP32
• STM32
• TI CC13x2
• Silabs Giant Gecko
• Plain connection usage examples
• Common options

Note that it's possible to combine multiple options if those operations are supported by the platforms, e.g. update the CLR and deploy a managed application in the same execution.

ESP32 usage examples

There are multiple ESP32 images available, some are build specifically for a target. Please check out the list. You will need as well to know the COM port used by your device. Find how to do this here. Alternatively, you can as well list the available COM ports. If you list them first without the device to flash and then plugging the device, the additional port which will show up is the one for the device to flash. This method works for all OS:

The ESP32_PSRAM_REV0 image will just work for any variant of the ESP32 series, with or without PSRAM, and for all silicon revisions. You can read more about the differences between the various images here.

The FEATHER_S2 image will just work for pretty much all variants of the ESP32-S2 series that expose the embedded USB CDC pins. You can read more about the differences between the various images here.

When using nanoff you can add --target MY_TARGET_NAME_HERE to use a specific image. If, instead, you just specify the platform with --platform esp32 nanoff will choose the most appropriate image depending on the features of the device that's connected. Output similar to this one will show to advise what's the image about to be used:

Note: Please note that for ESP32-S2 targets is not possible to safely determine what's the best image to use. For this reason it's mandatory providing the appropriate target name with --target MY_TARGET_NAME_HERE.

Some ESP32 boards have issues entering bootloader mode. This can be usually overcome by holding down the BOOT/FLASH button in the board. In case nanoff detects this situation the following warning is shown:

[!WARNING] To update FeatherS2, TinyS2 and some S3 modules, the board needs to be put in download mode by holding [BOOT], clicking [RESET] and then releasing [BOOT].

Update the firmware of an ESP32 target

To update the firmware of an ESP32 target connected to COM31, to the latest available development version.

Update the firmware of an ESP32-S2 KALUGA 1 with a local CLR file

To update the firmware of an ESP32-S2 KALUGA 1 target connected to COM31 with a local CLR file (for example from a build). This file has to be a binary file with a valid CLR from a build. No other checks or validations are performed on the file content.

You can adjust the name of the core image you want to use. Refer to the previous section to get the full list.

Show details of the connected ESP32 device

To show the details of the ESP32 device connected to COM31.

Optionally an extra parameter --checkpsram can be passed, which forces the detection of PSRAM availability.

Deploy a managed application to an ESP32 target

To deploy a managed application to an ESP32_PSRAM_REV0 target connected to COM31.

Note: The binary file with the deployment image can be found on the Release or Debug folder of a Visual Studio project after a successful build. This file contains everything that's required to deploy a managed application to a target (meaning application executable and all referenced libraries and assemblies).

Update the firmware of an ESP32 target along with a managed application

To deploy an application on an ESP32 target connected to COM31, with your application, you have to specify the path to the managed application. Optionally you can provide an address which will override the default deployment address. This example uses the binary format file that you can find when you are building an application. Note, as only application can run, when you are building a library, a bin file is not created automatically. Only for applications.

Skip backing up configuration partition

To skip backing up the configuration partition when updating the firmware of an ESP32 target connected to COM31.

STM32 usage examples

Update the firmware of a specific STM32 target

To update the firmware of the ST_STM32F769I_DISCOVERY target to the latest available stable version using the JTAG connection.

Deploy a managed application to a ST_STM32F769I_DISCOVERY target

To deploy a managed application to a ST_STM32F769I_DISCOVERY target, which has the deployment region at 0x08080000 flash address and reset the MCU after flashing it.

Note: The binary file with the deployment image can be found on the Release or Debug folder of a Visual Studio project after a successful build. This file contains everything that's required to deploy a managed application to a target (meaning application executable and all referenced libraries and assemblies).

Update the firmware of a ST_STM32F769I_DISCOVERY along with a managed application

To update the firmware of the ST_STM32F769I_DISCOVERY target to the latest available version, using a JTAG connection, along with a managed application. You have to specify the path to the managed application. This example uses the binary format file that is generated by Visual Studio when building any nanoFramework C# application. Because it's a binary file you have to specify too the flash address of the deployment region (here 0x08000000, mind the hexadecimal format).

List all STM32 devices available with JTAG connection

This useful to list all STM32 devices that are connected through JTAG.

List all STM32 devices available with DFU connection

This useful to list all STM32 devices that are connected through DFU.

Install STM32 JTAG drivers

To install the drivers for STM32 JTAG connected targets.

Install STM32 DFU drivers

To install the drivers for STM32 DFU connected targets.

TI CC13x2 usage examples

Update the firmware of a specific TI CC13x2 target

To update the firmware of the TI_CC1352R1_LAUNCHXL target to the latest version.

Install the XDS110 USB drivers required by TI LaunchPad targets

To install the XDS110 USB drivers.

Silabs Giant Gecko usage examples

Update the firmware of a specific Silabs target

To update the firmware of the SL_STK3701A target to the latest version.

Update the firmware of a Silabs target from a local file

To update the firmware of a Silabs target with a local firmware file (for example from a build). This file has to be a binary file with a valid Booter and CLR from a build. No checks or validations are performed on the file(s) content.

Deploy a managed application to a SL_STK3701A target

To deploy a managed application to a SL_STK3701A target, which has the deployment region at 0x000EE000 flash address and reset the MCU after flashing it.

Note: The binary file with the deployment image can be found on the Release or Debug folder of a Visual Studio project after a successful build. This file contains everything that's required to deploy a managed application to a target (meaning application executable and all referenced libraries and assemblies).

Update the firmware of a SL_STK3701A along with a managed application

To update the firmware of the SL_STK3701A target to the latest available version, using a J-Link connection, along with a managed application. You have to specify the path to the managed application. This example uses the binary format file that is generated by Visual Studio when building any nanoFramework C# application. Because it's a binary file you have to specify too the flash address of the deployment region (here 0x000EE000, mind the hexadecimal format).

List all Silabs devices available with J-Link connection

This useful to list all Silabs devices that are connected through J-Link.

Plain connection usage examples

It's possible to update a nano device using the same connection that is used for Visual Studio connection, meaning that no specialized connection is required (like JTAG, or JLink). This is only possible if the device has previously been flashed with a working nanoFramework firmware.

Update the CLR of a nano device

To update the CLR of a nano device connected to a serial port to the latest available version. This will find the latest available firmware for the connected device and will update the CLR.

Deploy a managed application

To deploy (or update) a managed application, the path to the managed application has to be provided. This example uses the binary format file that is generated by Visual Studio when building any nanoFramework C# application. Because it's possible to retrieve all the required details from the connected device no other configuration is required.

Update the CLR of a nano device from a local file

To update the firmware of a nano device with a local firmware file (for example from a build). This file has to be a binary file with a valid nanoCLR from a build. No checks or validations are performed on the file content.

Get details from a nano device

To get the details of a nano device connected to a serial port.

Common options

Pre-check if target fits connected device

The tool tries to make a best effort sanity check on whether the requested target fits the connected target. Sometimes that's not possible because of the differences and variations on the target names, or lack of details provided by the connected device or even (like with DFU connected devices) because it's not possible to determine exactly what device is connected at all. This doesn't necessarily mean that the firmware wont' work, so take this as an advice only.

To disable this validation add --nofitcheck option to the command line.

Tool output verbosity

The tool output verbosity can be set through the v|verbosity option.

This is convenient, for example, if this tool is being used in a automated process where the minimum output is desired to ease processing the return result of the execution. It can be set to:

• q[uiet]
• m[inimal]
• n[ormal]
• d[etailed]
• diag[nostic]

List connected nano devices

To get a list of connected nano devices. If more details are required add verbose option with setting above normal.

Output example:

Output example with verbose details:

Finding the device COM port on Windows

You need to know the COM Port attached to your device. Search for Computer Management, select Device Manager then expand Ports (COM & LPT), you will find the COM port of the connected device.

IMPORTANT: you may have to install drivers. Refer to the vendor website or use Windows Update to install the latest version of the drivers.

Finding the device COM port using nanoff

You can use the --listports command with nanoff to list the available COM ports. This method works on all OS. If you run the command first without your device plugged, you'll get a first list. Then plug your device and run the command again. The new COM port showing up is the one from your device!

Example of outcomes when there is no device plugged in:

And when you then plug the device and run the command again:

List targets

You can list the supported targets, and their version using the --platform parameter.

List packages available for ESP32 targets:

List packages available for STM32 targets:

If you use the --listtargets switch in conjunction with --preview, you'll get the list of available firmware packages that are available with experimental or major feature changes.

Deploy file to device storage

Some devices like ESP32, Orgpal and few others have storage available. Files can be deployed in this storage. You have to use the filedeployment parameter pointing on a JSON file to deploy files while flashing the device:

The JSON an optional SerialPort in case the port to upload the files must be different than the one to flash the device or not specified in the main command line and a mandatory list of Files entries. Each entry must contains DestinationFilePath, the destination full path file name and SourceFilePath to deploy content, otherwise to delete the file, the full path with file name of the source file to be deployed:

In the case you just want to deploy the files without any other operation, you can just specify:

In that case, the SerialPort must be present in the JSON file.

[!Note] If a file already exists in the storage, it will be replaced by the new one.

If a file does not exist and is requested to be deleted, nothing will happen, a warning will be displayed.

If a file can't be uploaded because of a problem, the deployment of the other files will continue and an error will be displayed.

Deploy Wireless, Wireless Access Point, Ethernet configuration and Certificates

You can upload Wireless, Wireless Access Point, Ethernet configurations and Certificates during the flash operation so that your device is ready to go and those elements do not need to be stored in the code or beforehand in the internal storage. Depending on your device, some options may not be available. So check out what is available on your device before trying to upload them. The --networkdeployment can be combined with any other option.

The json file can contains various configurations and thet are all optional:

The optional SerialPort can be used in case the port to upload the configurations is different than the one to flash the device or not specified in the main command line like in the previous example.

Here is a minimal example setting up a Wireless Client and a Wireless Access Point configuration at the same time:

See the section further to understand what are the mandatory fields and which ones are optionals.

Wireless Client options

The WirelessClient object represents the wireless configuration settings for a network deployment. It contains the following properties:

• Ssid:

  • Type: string
  • Format: 32 characters maximum.
  • Mandatory

• Password:

  • Type: string
  • Format: 64 characters maximum
  • Default: empty string meaning no password.
  • Optional

• Authentication

  • Type: string
  • Possible values (case insensitive): EAP, PEAP, WCN, OPEN, SHARED, WEP, WPA, WPA2, NONE
  • Description: the authentication type.
  • Default: if nothing is specified, the internal value is not going to be changed

• Encryption

  • Type string
  • Possible values (case insensitive): WEP, WPA, WPA2, WPA_PSK, WPA2_PSK2, Certificate, None
  • Description: the encryption type.
  • Default: if nothing is specified, the internal value is not going to be changed

• ConfigurationOption

  • Type: string
  • Possible values (case insensitive): None, Disable, Enable, AutoConnect, SmartConfig
  • Description: the configuration option.
  • Default: if nothing is specified, the internal value is not going to be changed

• RadioType

  • Type: string
  • Possible values (case insensitive): 802.11a, 802.11b, 802.11g, 802.11n
  • Description: the radio type.
  • Default: if nothing is specified, the internal value is not going to be changed

• DhcpEnabled:

  • Type: bool
  • Default: true
  • Optional
  • Description: a value indicating whether DHCP is enabled. If set to false, the IPv4Address and IPv4NetMask need to be set up.

• AutomaticDNS:

  • Type: bool
  • Default: true
  • Optional
  • Description: a value indicating whether automatic DNS is enabled. If set to false, Ipv4DNSAddress1 needs at least to be set.

• IPv4Address:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 address. This needs to be set if DhcpEnabled is false.

• IPv4NetMask:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 netmask. This needs to be set if DhcpEnabled is false.

• IPv4Gateway:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 gateway.

• IPv4DNSAddress1:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the primary IPv4 DNS address.

• IPv4DNSAddress2:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the secondary IPv4 DNS address.

• MacAddress:

  • Type: string
  • Format: AABBCCDDEEFF or AA:BB:CC:DD:EE:FF
  • Description: the MAC address.
  • Note: some devivces do not allow to be set up, please check your device first.

Wireless Access Point options

• Ssid:

  • Type: string
  • Format: 32 characters maximum.
  • Mandatory

• Password:

  • Type: string
  • Format: 64 characters maximum
  • Default: empty string meaning no password.
  • Optional

• Authentication

  • Type: string
  • Possible values (case insensitive): EAP, PEAP, WCN, OPEN, SHARED, WEP, WPA, WPA2, NONE
  • Description: the authentication type.
  • Default: if nothing is specified, the internal value is not going to be changed

• Encryption

  • Type string
  • Possible values (case insensitive): WEP, WPA, WPA2, WPA_PSK, WPA2_PSK2, Certificate, None
  • Description: the encryption type.
  • Default: if nothing is specified, the internal value is not going to be changed

• ConfigurationOption

  • Type: string
  • Possible values (case insensitive): None, Disable, Enable, AutoConnect, SmartConfig
  • Description: the configuration option.
  • Default: if nothing is specified, the internal value is not going to be changed

• RadioType

  • Type: string
  • Possible values (case insensitive): 802.11a, 802.11b, 802.11g, 802.11n
  • Description: the radio type.
  • Default: if nothing is specified, the internal value is not going to be changed

• IPv4Address:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 address.
  • Mandatory.

• IPv4NetMask:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 netmask.
  • Mandatory.

• IPv4Gateway:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 gateway.
  • Default: the IPv4Address value

• IPv4DNSAddress1:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the primary IPv4 DNS address.

• IPv4DNSAddress2:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the secondary IPv4 DNS address.

• MacAddress:

  • Type: string
  • Format: AABBCCDDEEFF or AA:BB:CC:DD:EE:FF
  • Description: the MAC address.
  • Note: some devivces do not allow to be set up, please check your device first.

Ethernet options

Represents an Ethernet configuration and here are the properties:

• DhcpEnabled:

  • Type: bool
  • Default: true
  • Optional
  • Description: a value indicating whether DHCP is enabled. If set to false, the IPv4Address and IPv4NetMask need to be set up.

• AutomaticDNS:

  • Type: bool
  • Default: true
  • Optional
  • Description: a value indicating whether automatic DNS is enabled. If set to false, Ipv4DNSAddress1 needs at least to be set.

• IPv4Address:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 address. This needs to be set if DhcpEnabled is false.

• IPv4NetMask:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 netmask. This needs to be set if DhcpEnabled is false.

• IPv4Gateway:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the IPv4 gateway.

• IPv4DNSAddress1:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the primary IPv4 DNS address.

• IPv4DNSAddress2:

  • Type: string
  • Format: 1.2.3.4 where 1, 2, 3 and 4 are bytes with values from 0 to 255.
  • Description: the secondary IPv4 DNS address.

• MacAddress:

  • Type: string
  • Format: AABBCCDDEEFF or AA:BB:CC:DD:EE:FF
  • Description: the MAC address.
  • Note: some devivces do not allow to be set up, please check your device first.

Device and CA Certificates

You can either base64 encode your certificates (DeviceCertificates and CACertificates) or provide a path on a certificate file (DeviceCertificatesPath and CACertificatesPath). Note that the certificate file can contain multiple certificates one after the other. This is especially usefull for CA certificates.

Clear cache location

If needed one can clear the local cache from the firmware packages that are stored there. As an additional information the cache location is the directory -nanoFramework\fw_cache in the user folder.

When this option is included in the command no other options are processed.

Firmware archive

By default, nanoff uses the online repository to look for firmware packages. It is also possible to use a local directory as the source of firmware. The firmware archive can be populated via the --updatearchive option:

For a list of archived firmware:

To install firmware on a device, use the same command line arguments as usual, but add --fromarchive and --archivepath:

Bypass version check

By default nanoff checks whether a new version of the tool has been published. If that is not necessary, the option --suppressnanoffversioncheck can be added to suppress the check.

Exit codes

The exit codes can be checked in this source file.

Telemetry

This tool is using anonymous telemetry to help us improve the usage. You can opt out by setting up an environment variable NANOFRAMEWORK_TELEMETRY_OPTOUT to 1.

The telemetry information is mainly related to the command line arguments, the firmware versions installed and any issue that can occurs during the code execution.

Feedback and documentation

To provide feedback, report issues and finding out how to contribute please refer to the Home repo.

Join our Discord community here.

Credits

The list of contributors to this project can be found at CONTRIBUTORS.

License

The nanoFramework firmware flasher tool is licensed under the MIT license.

Code of Conduct

This project has adopted the code of conduct defined by the Contributor Covenant to clarify expected behaviour in our community. For more information see the .NET Foundation Code of Conduct.

NET Foundation

This project is supported by the NET Foundation.