Page tree
Skip to end of metadata
Go to start of metadata
Q

How is a FDL structured?

How can I generate a Flash Device Label?

Where is the FDL stored?

A

The flash device label is a data structure, stored in the flash memory of a device. It is not netX 90 specific but a generic structure used by several Hilscher products.

The structure contains device individual, unique data like serial numbers, etc..
I.e. a unique FDL must be generated for each produced product.

Alternatively, this data can be provided by the host application over a DPM - dual port memory - mailbox service "Device Data Provider Set service".
This service is described in the manual netX Dual-Port Memory Packet-based services (netX 90/4000/4100)

FDL Layout

The structure of the FDL is specified in the document Storage of Device Parameters Application Note and netX 90 - Production guide, chapter "Flash Device Label (*.fdl)".

The following C-headerfile contains a respective structure declaration: Hil_DeviceProductionData.h.
Please refer to the latest release of the cifX/netX Toolkit (NXDRV-TKIT), which contains a set of "Hilscher Definitions" header files, including Hil_DeviceProductionData.h.

HIL_PRODUCT_DATA_LABEL_T
/*============================================================*/
/*                                                            */
/*! PRODUCTION Data - Device Label                            */
/*                                                            */
/*============================================================*/
typedef __HIL_PACKED_PRE struct HIL_PRODUCT_DATA_LABEL_Ttag
{

  HIL_PRODUCT_DATA_HEADER_T                 tHeader;
  HIL_PRODUCT_DATA_T                        tProductData;
  HIL_PRODUCT_DATA_FOOTER_T                 tFooter;

} __HIL_PACKED_POST HIL_PRODUCT_DATA_LABEL_T;
HIL_PRODUCT_DATA_T
/*------------------------------------------------------------*/
/*! PRODUCTION Data Structure                                 */
/*------------------------------------------------------------*/
/* Note: Structures should be aligned */
typedef __HIL_PACKED_PRE struct HIL_PRODUCT_DATA_Ttag
{
  HIL_PRODUCT_DATA_BASIC_DEVICE_DATA_T        tBasicDeviceData;
  HIL_PRODUCT_DATA_MAC_ADDRESSES_COM_T        tMACAddressesCom;
  HIL_PRODUCT_DATA_MAC_ADDRESSES_APP_T        tMACAddressesApp;
  HIL_PRODUCT_DATA_PRODUCT_IDENTIFICATION_T   tProductIdentification;
  HIL_PRODUCT_DATA_OEM_IDENTIFICATION_T       tOEMIdentification;
  HIL_PRODUCT_DATA_LIBSTORAGE_T               tFlashLayout;

} __HIL_PACKED_POST HIL_PRODUCT_DATA_T;



FDL file generation

There are several ways to generate a Flash Device Label.

Hilscher`s netX Studio Development tool features a FDL Wizard to generate template files for various use cases and a FDL Editor to modify the content.
These tools are meant to be used during product development.

Since the FDL contains unique device specific data like serial number and MAC addresses, each produced device requires a unique FDL file.
Two possibilities:

  1. patch an existing FDL
    i.e. just replace the serial number and MAC addresses and update the checksum

  2. create a FDL file using a program or script
    - usage of the C-header file Hil_DeviceProductionData.h might be useful
    - Hilscher provides an example Python script for FDL generation.
      This example script is provided "as is", without warranty and support!
      The script might be used as a base for own development.


FDL storage

The FDL binary is stored at a fixed address in the netX 90 COM-side Flash Memory INTFLASH0. The offset address is 0x2000, the fixed size is 0x1000 Bytes (4KB).
Please refer also to the Video Tutorial "Flash Memory Layout"



FDL content

Basic Device Data

(warning) The Basic Device Data is related to the Firmware validation for LFW(Protocol stacks) and APP-FW.
If custom changes are performed to the Basic Device Data, the File Header (*.nxi, *.nai file) might be modified as well in order to meet the firmware validation requirements.

Please note that a user cannot define it's own manufacturer code. These are managed and assigned by Hilscher.

The Basic Device Data is not used for protocol stack specific purposes. For this case, the OEM Identification data might be used.

Basic Device Data Fields

  • Manufacturer ID -    0 = Undefined; 1 - 255 = Hilscher GmbH; 256 - x = OEM - All numbers are managed and assigned by Hilscher GmbH
  • Device classification number -    Possible values are defined in the dual port memory definitions (see HIL_HW_DEV_CLASS_*).
  • Device number  - For usManufacturer 1-255 the numbers are managed by Hilscher GmbH.
  • Serial number -   For usManufacturer 1-255 the serial number of the device is managed by Hilscher GmbH.
  • Hardware compatibility number -  This number indicates an incompatible hardware change
  • Hardware revision number - Production related hardware revision number
  • Production date -  uint16_t format is 0xYYWW

MAC AddressesCom

Unique MAC addresses for the Communication Firmware. Each device must contain a unique FDL with unique MAC addresses in this section.
Typically up to 4 MAC addresses are required for one single device, depending on the used firmware and features. Please refer to MAC Adresses for Loadable Firmware Protocol Stacks for further details.

MAC AddressesApp

Optional unique MAC addresses for the application side. Typically not required for netX 90 based devices.

Product Identification

USB Vendor and Product IDs. Typically not required for netX 90 based devices.

OEM Identification

Optional usable data for device identification.The single data fields can be enabled/disabled separately.

(warning) Note: However some loadable firmwares (LFWs) might require the enabling of several data fields simultaneously.
E.g. PROFINET V5.3 requires fields 0-2 = Serial number, Order number and Hardware revision to be enabled.
Please refer to the respective Protocol Stack API Manual

figure: PROFINET LFW V5.3 API manual excerpt


This data is evaluated by the data provider component in the LFW and forwarded to the protocol stack.
The communication protocol stack might use this data for device identification purposed towards the network master (PLC). E.g. PROFINET I&M data.

Alternatively, this data can be provided by the host application over a DPM - dual port memory - mailbox service "Device Data Provider Set service".
This service is described in the manual netX Dual-Port Memory Packet-based services (netX 90/4000/4100)

OEM Identification Data Fields

  • Serial number (char string)
  • Order number (char string)
  • Hardware revision (char string)
  • Production date/time (char string)
  • Vendor specific data (byte array)


Flash Layout

Information about the number and size of flash memories, both internal and external, in the system accessed by Hilscher LFW - Loadable Firmware.

Information about the location and size of specific components (like *.hwc, *.nxi, etc.) in the flash memories. This information is required by Hilscher LFWs.

(warning) We recommend to stick to the default settings, as generated by the netXSTUDIO FDL creation tool.


Related Video Tutorials
Disclaimer

IMPORTANT! Please read this carefully before you install the software!

Exclusion of Liability for this demo software

The following software is intended for and must only be used for reference and in an evaluation laboratory environment. It is provided without charge and is subject to alterations. Hilscher cannot guarantee uninterrupted use thereof, or that the Software is free of errors and defects. The Software was produced and tested by Hilscher with only evaluation laboratory environment. Hilscher cannot make any warranty that the Software is functional or free of errors when the Software is used by the user. It is the user's obligation to fully test the software in its environment and to ensure proper functionality, qualification and compliance with component specifications.   


1. Disclaimer of Warranty

There is no warranty for the software, to the extent permitted by applicable law. Except when otherwise stated in writing the copyright holders and/or other parties provide the software "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the quality and performance of the software is with you. Should the software prove defective, you assume the cost of all necessary servicing, repair or correction.


2. Limitation of Liability

In no event unless required by applicable law or agreed to in writing will any copyright holder, or any other party who modifies and/or conveys the software as permitted above, be liable to you for damages, including any general, special, incidental or consequential damages arising out of the use or inability to use the software (including but not limited to loss of data or data being rendered inaccurate or losses sustained by you or third parties or a failure of the software to operate with any other softwares), even if such holder or other party has been advised of the possibility of such damages.


If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Software.

By installing or otherwise using the software, you accept the terms of this Agreement.

If you do not agree to the terms of this Agreement, then do not install or use the Software!