2nd-Stage-Bootloader & Bootstrap [EN]

Background

Basically, all netX based field bus devices can only run a specific protocol stack, by using a fitting firmware and configuration. Those have to be downloaded via the host interface (PCI, PCIe, SPI etc.). So-called "RAM-based devices" (CifX cards) don’t have persistent memory for firmware and configuration, and are therefore supplied with both files at each device start by the driver. In this case, it is loaded directly to the RAM of the device and executed immediately. The firmware and configuration are lost, and the procedure needs to be started from the beginning, after every power cycle.

Whether RAM- or Flash-based devices, in both cases the device driver usually takes over the task of downloading the required files. For this purpose, the driver has a defined basic-directory which is created when installing the driver:

  • Windows: C:\Program Files\cifX Device Driver
  • Linux: /opt/cifx/

The driver loads the firmware (.nxf) and configuration (.nxd) file from this directory, to the device. Concerning Flash-based devices, a download only takes place if a difference between the software versions is detected.

2nd-Stage-Bootloader

If a device is in the delivery state, it provides a simplified DPM interface (see following figure). The size of the DPM is limited to 64KByte (16KByte / 8KByte) and does not allow the download of a firmware file. Therefore, the device must first be supplied with a so-called 2nd stage boot load.



The 2nd-stage bootloader can be transferred to the device in file form. The different files for different device types are located in the above directory. The 2nd-stage bootloaders are present in the form of NETX***-BSL.BIN files. For example, you need the NETX100-BSL.BIN file for a CifX card.

Firmware download

If the 2nd-stage bootloader has been successfully loaded and started, the DPM is reorganized, and a simplified system mailbox is provided, comparable to the known channel mailbox. The mailbox now allows the segmented transfer of larger files, such as the firmware file.



Basically, it is also possible to view this procedure in the cifX/netX-Toolkit in the form of source code. In the Toolkit the methods of the drivers are implemented. They make it possible for customers, to implement their own drivers, if necessary for not supported operating systems or platforms. Specifically, the cifXInit.c can be interesting here. The file contains the cifXStartBootloader_hboot(...) function. It implements the procedure described above.

cifX/netX-Tookit https://hilscher.atlassian.net/wiki/pages/viewpage.action?pageId=80904557 

File Handling

Within the basic directory (see above), a folder is created for each device installed on the PC according to the following structure.


Note: For normal field bus communication, Channel0 is always used. Channel1 can be used for multichannel operation or special applications. Multichannel operations requires appropriate hardware equipment.

By replacing the files, the firmware or the configuration can be exchanged. When replacing, it is important to ensure that the configuration fits the firmware. In addition, the configuration file must always be named "config.nxd".

After replacing a file, the card needs to be restarted. This can be done through the xSysdeviceReset () function of the Cifx API.