Skip to end of banner
Go to start of banner

Firmware update

Skip to end of metadata
  • Created by Former user, last modified on 2019-06-07
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Q

How is a running loadable firmware on COM-side (LFW - .nxi file) or APP-side (*.nai file) replaced by a newer version in the field?

A


The following steps are necessary

1) Transfer of new firmware to netX 90

The 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:

  1. HTTP protocol over the network (Ethernet), using the basic webserver functionality of a running LFW
  2. 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"
  3. 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
    use case c: location of the fwupdate.zip file or *.nxi, *.nai files in the filesystem: directory /FWUPDATE
  4. 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
    use case c: location of the fwupdate.zip file or *.nxi, *.nai files in the filesystem: directory /FWUPDATE
  5. The UART Marshaller and the PC Utility netHOST.exe

Use Case B

  1. 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
  2. Custom TCP/IP based protocol over the network (Ethernet), using the socket interface functionality of a running LFW
  3. 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 memory

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 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


3) Trigger the start of the maintenance firmware

The 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

  1. By pulling the RUN-pin to GND and performa a hardware reset
  2. 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...9Unused
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 firmware

The 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 netX90

After 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 info

ZIP 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).

Firmware update area

The location used for firmware update files depends on the use case.

FLASH (use case A & B)

If a flash area is used for the firmware update, the location for the update area is defined in the FDL with the ID: HIL_PRODUCT_DATA_FLASH_LAYOUT_CONTENT_TYPE_FWUPDATE. Only one file can reside in this area at a time.

The FWUPDATE area is reserved for firmware files or an update container. Therefore other files will not be accepted by the download request.

The download request will only support files with the suffix's:

  • NAI
  • NXI

Or the update container "FWUPDATE.ZIP".

File system (use case C)

If a target has file system support, firmware, configurations, files, as well as the update container, are stored in a default file system layout. The location used for storing update files is the /FWUPDATE directory.

The file system location itself is defined in the FDL with the ID: HIL_PRODUCT_DATA_FLASH_LAYOUT_CONTENT_TYPE_FILESYSTEM.

Contrary to use case A/C, use case C supports all possible files (as long as the 8.3 file format is followed).

The download request will treat the following file types differently:

  • NAI
  • NXI

Or the update container with the name "FWUPDATE.ZIP".

If one of those files is received using the download request on PORT_0 (ulChannelNo set to 0), the file is automatically transferred to the /FWUPDATE directory (it will not be visible on /PORT_0). Other files residing in the FWUPDATE directory will be deleted before the download of the new file starts.

The contents of the /FWUPDATE directory are only deleted if a new firmware file or update container is downloaded. They are not deleted during or after a firmware installation. This way, the firmware can be installed again (without an additional download) if, for some reason, the original firmware is destroyed.

The default file system layout is:

File System Layout

File System Root
├───SYSTEM
├───PORT_0
├───PORT_1
...
├───PORT_5
└───FWUPDATE






See also...

  • No labels