Document Language: English | 中文简体
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.
Perform a one-time install of the .NET nanoFramework Firmware Flasher tool using the following .NET Core CLI command:
dotnet tool install -g nanoffAfter 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:
You can invoke the tool using the following command: nanoff
Tool 'nanoff' (version '9.9.9') was successfully installed.
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:
dotnet tool install nanoff --tool-path c:\a-plain-simple-path-to-install-the-toolNote that if you're not using nanoff with STM32 devices, this limitation does not apply.
You'll need to add nanoff to your path as well, once installed run:
export PATH=$PATH:~/.dotnet/toolsTo update .NET nanoFramework Firmware Flasher tool use the following .NET Core CLI command:
dotnet tool update -g nanoffIf the tool was installed at a specific path, use the following .NET Core CLI command instead:
dotnet tool update nanoff --tool-path c:\path-where-the-tool-was-installedOnce the tool is installed, you can call it by using its command nanoff, which is a short version of the name to ease typing.
nanoff [command] [args]The tool includes help for all available commands. You can see a list of all available ones by entering:
nanoff --helpList of usage examples per platform and 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.
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:
nanoff --listportsThe 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:
No target name was provided! Using 'ESP32_REV0' based on the device characteristics.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:
*** Hold down the BOOT/FLASH button in ESP32 board ***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].
To update the firmware of an ESP32 target connected to COM31, to the latest available development version.
nanoff --update --target ESP32_PSRAM_REV0 --serialport COM31To 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.
nanoff --update --target KALUGA_1 --serialport COM31 --clrfile "C:\nf-interpreter\build\nanoCLR.bin" You can adjust the name of the core image you want to use. Refer to the previous section to get the full list.
To show the details of the ESP32 device connected to COM31.
nanoff --platform esp32 --serialport COM31 --devicedetails Optionally an extra parameter --checkpsram can be passed, which forces the detection of PSRAM availability.
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).
nanoff --target ESP32_PSRAM_REV0 --serialport COM12 --deploy --image "E:\GitHub\nf-Samples\samples\Blinky\Blinky\bin\Debug\Blinky.bin"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.
nanoff --target ESP32_PSRAM_REV0 --update --serialport COM31 --deploy --image "c:\eps32-backups\my_awesome_app.bin" --address 0x1B000To skip backing up the configuration partition when updating the firmware of an ESP32 target connected to COM31.
nanoff --update --target ESP32_PSRAM_REV0 --serialport COM31 --nobackupconfigTo update the firmware of the ST_STM32F769I_DISCOVERY target to the latest available stable version using the JTAG connection.
nanoff --update --target ST_STM32F769I_DISCOVERY --jtagTo 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).
nanoff --target ST_STM32F769I_DISCOVERY --deploy --image "E:\GitHub\nf-Samples\samples\Blinky\Blinky\bin\Debug\Blinky.bin" --address 0x08040000 --resetTo 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).
nanoff --update --target ST_STM32F769I_DISCOVERY --jtag --binfile "c:\dev\my awesome app\bin\debug\my_awesome_app.bin" --address 0x08000000This useful to list all STM32 devices that are connected through JTAG.
nanoff --listjtagThis useful to list all STM32 devices that are connected through DFU.
nanoff --listdfuTo install the drivers for STM32 JTAG connected targets.
nanoff --installjtagdriversTo install the drivers for STM32 DFU connected targets.
nanoff --installdfudriversTo update the firmware of the TI_CC1352R1_LAUNCHXL target to the latest version.
nanoff --update --target TI_CC1352R1_LAUNCHXLTo install the XDS110 USB drivers.
nanoff --installxdsdriversTo update the firmware of the SL_STK3701A target to the latest version.
nanoff --update --target SL_STK3701ATo 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.
nanoff --update --platform gg11 --binfile "C:\nf-interpreter\build\nanobooter-nanoclr.bin" --address 0x0To 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).
nanoff --target SL_STK3701A --deploy --image "E:\GitHub\nf-Samples\samples\Blinky\Blinky\bin\Debug\Blinky.bin" --address 0x000EE000To 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).
nanoff --update --target SL_STK3701A --binfile "c:\dev\my awesome app\bin\debug\my_awesome_app.bin" --address 0x000EE000This useful to list all Silabs devices that are connected through J-Link.
nanoff --listjlinkIt'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.
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.
nanoff --nanodevice --update --serialport COM9To 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.
nanoff --nanodevice --deploy --serialport COM9 --image "c:\dev\my awesome app\bin\debug\my_awesome_app.bin"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.
nanoff --nanodevice --update --serialport COM9 --clrfile "C:\nf-interpreter\build\nanoclr.bin"To get the details of a nano device connected to a serial port.
nanoff --nanodevice --devicedetails --serialport COM9The 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.
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]
nanoff -v qTo get a list of connected nano devices. If more details are required add verbose option with setting above normal.
nanoff --listdevices [ -v d ]Output example:
-- Connected .NET nanoFramework devices --
SKY_EEVB_Debug @ COM7
------------------------------------------
Output example with verbose details:
-- Connected .NET nanoFramework devices --
SKY_EEVB_Debug @ COM7
Target: SKY_EEVB_Debug
Platform: GGECKO_S1
Date: May 31 2023
Type: MinSizeRel build with Azure RTOS v6.2.0
CLR Version: 1.8.1.124
------------------------------------------
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.
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!
nanoff --listportsExample of outcomes when there is no device plugged in:
No available COM port
And when you then plug the device and run the command again:
Available COM ports:
COM12
You can list the supported targets, and their version using the --platform parameter.
List packages available for ESP32 targets:
nanoff --listtargets --platform esp32List packages available for STM32 targets:
nanoff --listtargets --platform stm32If 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.
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:
nanoff --target XIAO_ESP32C3 --update --masserase --serialport COM21 --filedeployment C:\path\deploy.jsonThe 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:
{
"serialport":"COM42",
"files": [
{
"DestinationFilePath": "I:\\TestFile.txt",
"SourceFilePath": "C:\\tmp\\NFApp3\\NFApp3\\TestFile.txt"
},
{
"DestinationFilePath": "I:\\NoneFile.txt"
},
{
"DestinationFilePath": "I:\\wilnotexist.txt",
"SourceFilePath": "C:\\WRONGPATH\\TestFile.txt"
}
]
}In the case you just want to deploy the files without any other operation, you can just specify:
nanoff --filedeployment C:\path\deploy.jsonIn 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.
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.
nanoff --clearcacheBy 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:
nanoff --updatearchive --target ESP32_S3_ALL --archivepath c:\...\firmware
nanoff --updatearchive --platform esp32 --archivepath c:\...\firmwareFor a list of archived firmware:
nanoff --listtargets --fromarchive --archivepath c:\...\firmwareTo install firmware on a device, use the same command line arguments as usual, but add --fromarchive and --archivepath:
nanoff --nanodevice --update --serialport COM9 --fromarchive --archivepath c:\...\firmwareBy 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.
The exit codes can be checked in this source file.
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.
To provide feedback, report issues and finding out how to contribute please refer to the Home repo.
Join our Discord community here.
The list of contributors to this project can be found at CONTRIBUTORS.
The nanoFramework firmware flasher tool is licensed under the MIT license.
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.
This project is supported by the NET Foundation.