The following steps are necessary- Transfer new firmware (*.nxi file and/or *.nai file) to netX 90
- Store the new fimware binary in a flash memory
- Trigger the start of the maintenance firmware - MFW - (alternative firmware)
- The maintenance firmware installs the new loadable firmware on COM-side (LFW - .nxi file) and/or APP-side (*.nai file). I.e. the old firmware is updated.
- The maintenance firmware reboot the netX90 and the new LFW is started
1) Transfer of new firmware to netX 90The new firmware may be
a) a COM-side firmware (*.nxi file)
b) an APP-side firmware (*.nai file)
c) both
In case of c) *.nxi and *.nai files are put into a ZIP archive.
It is even possible to store several *.nxi files (variants) into one ZIP archive. Depending on the flash layout use case A, B or C, either the COM-side Firmware (LFW) or the APP-side is responsible for the subsequent storage of the new firmware im flash memory (step 2) Also the The new firmware binary can be transferred through Use case A, C: - HTTP protocol over the network (Ethernet), using the basic webserver functionality of a running LFW
- Custom TCP/IP based protocol over the network (Ethernet), using the socket interface functionality of a running LFW
In this case, the APP-side Firmware transfers the received fimware update image to the COM-side by using
the cifX API function xChannelDownload() or the underlaying mailbox packet service "HIL_FILE_DOWNLOAD_REQ" - From an external Host-Controller, via the host interface - HIF: parallel DPM or serial SPM (SPI)
using the cifX API function xChannelDownload() or the underlaying mailbox packet service "HIL_FILE_DOWNLOAD_REQ"
in this case the host application communicates with a running LFW or the MFW on COM-side - From the APP-side of netX 90 via the internal DPM
using the cifX API function xChannelDownload() or the underlaying mailbox packet service "HIL_FILE_DOWNLOAD_REQ"
in this case the host application communicates with a running LFW or the MFW on COM-side - The UART Marshaller and the PC Utility netHOST.exe
Use Case B - HTTP protocol over the network (Ethernet), using the basic webserver functionality of a running LFW
In this case, the COM-side LFW transfers the received fimware update image to the APP-side firmeware via mailbox packets - Custom TCP/IP based protocol over the network (Ethernet), using the socket interface functionality of a running LFW
- Any communication interface (UART, I2C, SPI, etc.) and custom protocol to the APP side of netX 90
2) Store the new fimware binary in a flash memoryDepending on the flash layout use case A, B or C, either the COM-side Firmware (LFW) or the APP-side is responsible for the flash programming Use Case A and C: The flash programming is performed by the running LFW or MFW on COM side. The user application on APP-side or an external host is not responsible for flash programming.
The new firmware is stored in the so called "update area". I.e. after flash programming there are two firmware files inside the flash: a) the active firmware, b) the new firmware Use Case B: The APP-side firmware is responsible to program the new firmware file into the external flash memory update area.
The new firmware is stored in the so called "update area". I.e. after flash programming there are two firmware files inside the flash: a) the active firmeare, b) the new firmware
 Image Modified3) Trigger the start of the maintenance firmwareThe maintenance firmware - MFW - is responsible for the actual installation of the new firmware. It erases the old firmware in flash and copies the new firmware into the firmware location. The MFW can be started - By pulling the RUN-pin to GND and performa a hardware reset
- By Software: Sending the mailbox packet
HIL_FIRMWARE_RESET_REQ
The firmware reset request (HIL_FIRMWARE_RESET_REQ → 0x00001E00) has two parameters: - ulTimeToReset (unused)
- ulResetMode
By changing the ulResetMode parameter in the reset request packet, a running LFW is able to execute a reset and jump to the MFW to start the update process. | 31...9 | Unused | | 8 | Delete complete remanent data area 1 = Delete the complete remanent data area.
0 = Do not delete the remanent data area.
If this bit is set to 1 and the MFW is started using mode HIL_RESET_MODE_UPDATESTART, the complete remanent data area is deleted after a successful firmware update and the MFW will automatically restart to the LFW. If this bit is set to 1 and the MFW is started using mode HIL_RESET_MODE_BOOTSTART, the complete remanent data area is deleted during the startup of the MFW and the MFW will not restart to the LFW. This parameter is not supported for HIL_RESET_MODE_COLDSTART. | | 7...4 | Reset Parameter for HIL_RESET_MODE_COLDSTART - Does not support reset parameters.
for HIL_RESET_MODE_BOOTSTART - Does not support reset parameters.
for HIL_RESET_MODE_UPDATESTART - 0x0...0xF: If a ZIP file is used for the update, this option specifies the firmware that should be installed (Multi-Protocol Firmware).
| | 3...0 | Reset Mode 0 = HIL_RESET_MODE_COLDSTART
1 = HIL_RESET_MODE_WARMSTART (unused)
2 = HIL_RESET_MODE_BOOTSTART
3 = HIL_RESET_MODE_UPDATESTART
The cold start will perform a reset of the device and start the installed LFW again. The boot start will perform a reset of the device and start the MFW. The boot start can be used to jump to the MFW without starting an update process (idle mode). The update start will perform a reset of the device and start the MFW. If an update file is available, it will be automatically processed and installed. |
4) The maintenance firmware installs the new loadable firmwareThe maintenance firmware - MFW - is responsible for the actual installation of the new firmware. It erases the old firmware in flash and copies the new firmware into the firmware location.
The desitination is determined by the file type *.nxi, *.nai
It automatically detects the file type *.nxi, *.nai or *.zip by evaluation of the binary file headers. Before the installation, checksums are calculated/compared and device and manufacturer IDs are checked to avoid installation of corrupt or wrong firmware images. 5) The maintenance firmware reboot the netX90After completion of the installation process, the MFW performs a reboot of the system. Now the newly installed loadable firmware is started.
In case of a hardware triggered MFW start (RUN-pin pulled to GND) the RUN-pin must be released before the system reboot. Further infoZIP Container Format: File System Root
├───var0
├───SYSTEM
├───PORT_0
├───PORT_1
...
├───PORT_5
└───XIP
├───var1
├───SYSTEM
├───PORT_0
├───PORT_1
...
├───PORT_5
└───XIP
...
By using this layout, multiple firmware files can be placed in a single update container and installed by specifying the variant in the reset parameter described below. The XIP directories hold the firmware file (with an 8.3 name format) that will be installed to the device (NXI/NXE/NAI/NAE). Files located in the SYSTEM and PORT_X directories will be installed to the corresponding directories on the file system (only use case C).
|