Manuals+

i.MXRT10XX Safety Example User's Guide

Document Identifier: IEC60730BIMXRT10XXEUG

Revision: 0, 12/2020

Chapter 1 IEC60730B Safety library example user's guide

For easier development of the IEC60730B application, the library also provides the example code. This example is distributed through the MCUXpresso SDK website. This example user's guide describes how to set the hardware correctly and how to use the example code with the IEC60730B Safety library. The library user's guide is the main documentation for IEC60730B. It is also part this package and accessible at www.nxp.com/IEC60730.

Chapter 2 Hardware settings

This chapter describes how to set up the hardware of the evaluation board. The MCU peripherals' setup is described later on. The IEC60730B library example for the I.MXRT family supports the following development boards:

To run the IEC60730B example application, it is necessary to make some hardware settings. For the default configuration of your development board, see the corresponding board's user manual at www.nxp.com.

2.1 EVK-MIMXRT1010

To use the on-board debugger and power the board via USB, make sure that jumper J1 has the 1-2 pins shorted. Connect the USB to connector J41. The SW8 switch is used to select the boot mode. Set SW8 to boot from the QSPI flash (1-OFF, 2-OFF, 3-ON, 4-OFF). See the MIMXRT1010 EVK Board Hardware User's Guide (document MIMXRT1010EVKHUG) for more power and boot options. The ADC module on EVK-MIMXRT1010 does not allow the VrefL and Bandgap to connect internally to the ADC input. Connect these signals (for Analog I/O test) as follows:

Description of Figure 1: Hardware connection of EVK-MIMXRT1010. This image shows the physical connections made to the EVK-MIMXRT1010 development board for testing purposes, illustrating jumper settings and external connections for analog I/O tests.

2.2 EVK-MIMXRT1020

To use the on-board debugger and power the board via USB, make sure that jumper J1 has pins 5-6 shorted. Connect the USB to connector J23. The SW8 switch is used to select the boot mode. Set SW8 to boot from the QSPI flash (1-OFF, 2-OFF, 3-ON, 4-OFF). See the MIMXRT1020 EVK Board Hardware User's Guide (document MIMXRT1020EVKHUG) for more power and boot options. The ADC module on EVK-MIMXRT1020 does not allow the VrefL and Bandgap to connect internally to the ADC input. Connect these signals (for the Analog I/O test) as follows:

Description of Figure 2: Hardware connection of EVK-MIMXRT1020. This image displays the hardware setup for the EVK-MIMXRT1020 board, detailing jumper configurations and external wiring for analog signal inputs.

2.3 EVK-MIMXRT1024

To use the on-board debugger and power the board via USB, make sure that jumper J1 has pins 5-6 shorted. Connect the USB to connector J23. The SW8 switch is used to select the boot mode. Set the SW8 to boot from the QSPI flash (1-OFF, 2-OFF, 3-ON, 4-OFF). See the MIMXRT1024 EVK Board Hardware User's Guide (document MIMXRT1020EVKHUG) for more power and boot options. The ADC module on EVK-MIMXRT1020 does not allow the VrefL and Bandgap to connect internally to the ADC input. Connect these signals (for the Analog I/O test) as follows:

Description of Figure 3: Hardware connection of EVK-MIMXRT1024. This image illustrates the physical connections for the EVK-MIMXRT1024 development board, including jumper settings and external wiring for analog I/O tests.

2.4 EVKB-IMXRT1050

To use the on-board debugger and power the board via USB, make sure that jumper J1 has pins 5-6 shorted. Connect the USB to connector J41. The SW7 switch is used to select the boot mode. Set the SW7 to boot from the QSPI flash (1-OFF, 2-ON, 3-ON, 4-OFF). See the IMXRT1050 EVKB Board Hardware User's Guide (document IMXRT1050EVKBHUG) for more power and boot options. The ADC module on EVKB-IMXRT1050 does not allow to connect VrefL and Bandgap internally to the ADC input. Connect these signals (for the Analog I/O test) as follows:

Description of Figure 4: Hardware connection of EVKB-IMXRT1050. This image shows the hardware setup for the EVKB-IMXRT1050 board, detailing jumper configurations and external wiring for analog signal inputs.

2.5 EVK-MIMXRT1060

To use the on-board debugger and power the board via USB, make sure that jumper J1 has pins 5-6 shorted. Connect the USB to connector J41. The SW7 switch is used to select the boot mode. Set the SW7 switch to boot from the QSPI flash (1-OFF, 2-OFF, 3-ON, 4-OFF). See the MIMXRT1060 Evaluation Kit Board Hardware User's Guide (document UM11151UG) for more power and boot options. The ADC module on EVK-MIMXRT1060 does not allow to connect VrefL and Bandgap internally to the ADC input. Connect these signals (for the Analog I/O test) as follows:

Description of Figure 5: Hardware connection of EVK-MIMXRT1060. This image displays the hardware setup for the EVK-MIMXRT1060 development board, including jumper settings and external wiring for analog I/O tests.

Chapter 3 File structure

Safety is only a small part of the whole SDK package for your device. The IEC60730 library and examples are located in the middleware and in the board folders. The IEC60730 library is independent of the SDK and can be used stand-alone.

3.1 Library source files location

The library source files are in the middleware/safety_iec60730b/safety/v4_1 folder in the SDK package.

Description of Folder Structure: The library source files are organized within the SDK package in the middleware/safety_iec60730b/safety/v4_1 directory. This structure includes subfolders like [common_test], [compiler], [core_test], and directories for different IDE compilers (Keil, MCUXpresso, IAR) containing compiled libraries (e.g., libIEC60730B_M4_M7_KEIL_v4_1). Key header files include iec60730b.h and iec60730b_types.h.

3.2 Example of library handling code

The library-handling code and the example application are separate from the library file. The example source files and other SDK examples are at this path: boards/<your board>/demo_apps/safety_iec60730b/

Description of Figure 6: Example of project structure in example folder. This diagram shows the typical file and folder organization for the safety example code, including IDE-specific project folders (iar, mcux, mdk) and generated configuration files like clock_config.h and pin_mux.c.

This folder contains the example source file and three folders for the IDE project file:

The following files are generated by the MCUXpresso configuration tool:

Other files are used only for safety examples and their contents are described in the next chapter.

Chapter 4 Example application

The structure of the example is common in all supported IDEs (IAR, Keil, MCUXpresso).

Description of Figure 7: IAR example application structure. This screenshot displays the project file structure within the IAR Embedded Workbench IDE, highlighting folders for CMSIS, SDK components, board support, CPU startup, device registers, drivers, FreeMASTER, the IEC60730B Class B library, and source files.

The project contains the CMSIS, SDK, library, and safety example-related folders. The safety-related folders are the following:

Description of Figure 8: Example of project hierarchy. This diagram illustrates the relationships between key source files in the safety example, showing how main.c calls functions from project_setup.c and library handling functions, and how various safety test modules (safety_config.h, safety_cm0.c, safety_test_items.c, etc.) interact with the IEC60730 Class B library.

4.1 How to open the project

IAR IDE: Open the project file located at boards/<your_board>/demo_apps/safety_iec60730b/iar/safety_iec60730b.eww.

Arm Keil IDE: Open the project file located at boards/<your_board>/demo_apps/safety_iec60730b/mdk/safety_iec60730b.uvprojx.

MCUXpresso IDE: Firstly, drag and drop the <name_of_the_package>.zip package into the MCUXpresso IDE (into the "Installed SDKs" tab). Secondly, import the SDK example (safety_iec60730b).

If you are not familiar with the MCUXpresso IDE yet, see docs/Getting Started with MCUXpresso SDK for <your_board>.pdf ("Build an example application" section).

4.2 Example settings - safety_config.h

The main example settings header file is safety_config.h. The necessary macros for the safety example are defined in this file. The "switch macros", which enable the user to turn off calling of the safety test, are defined in the beginning. When starting, turn off the FLASH test and the WDOG test. On LPC devices, turn off also the Clock test.

/* This macro enables infinity while loop in SafetyErrorHandling() function */
#define SAFETY_ERROR_ACTION 1
/* TEST SWITCHES - for debugging it is better to turn the flash test and watchdog OFF */
#define ADC_TEST_ENABLED 1
#define CLOCK_TEST_ENABLED 1
#define DIO_TEST_ENABLED 1
#define FLASH_TEST_ENABLED 1
#define PC_TEST_ENABLED 1
#define WATCHDOG_ENABLED 1
#define FMSTR_SERIAL_ENABLE 1

Other defines are used to configure the safety test as a parameter to a function or to fill structures.

4.3 safety_test_items.c file

The safety_test_items.c and .h files are the configuration files for the DIO test. The file contains the fs_dio_test_<platform>_t list of structures. The pointers to these structures are collected in the dio_safety_test_items[] array, which is used in the example application.

#define MUX_ADDR(arg1) MUX_ADDR_(arg1) /* wrapper */
#define MUX_ADDR_(arg1, arg2, arg3, arg4, arg5) arg1 /* get 1st value from macro */
#define PAD_ADDR(arg1) PAD_ADDR_(arg1) /* wrapper */
#define PAD_ADDR_(arg1, arg2, arg3, arg4, arg5) arg5 /* get 5th value from macro */
fs_dio_test_imx_t dio_safety_test_item_0 =
{
  .gpio = GPIO1_BASE,
  .pinNum = 15U,
  .pinDir = PIN_DIRECTION_IN,
  .muxAddr = MUX_ADDR(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15),
  .padAddr = PAD_ADDR(IOMUXC_GPIO_AD_B0_15_GPIO1_IO15),
};
/* NULL terminated array of pointers to dio_test_t items for safety DIO test */
fs_dio_test_imx_t* dio_safety_test_items[] = { &dio_safety_test_item_0, &dio_safety_test_item_1, NULL };

4.4 Source file - safety_safety_cm4_cm7_<platform>.c/.h

The safety_cm4_cm7_imx8m.csafety_cm4_cm7_imxrt.c source file and the corresponding *.h file contain a library handling function. Each function contains a detection. If a safety error occurs, the SafetyErrorHandling() function is called.

Description of Figure 9: Example of setting MAP files for FRDM-KV11 board. This image shows the FreeMASTER IDE configuration window for setting the default symbol file, which is crucial for linking the monitoring tool to the application's variables.

Description of Figure 10: Setting UART speed. This image displays the FreeMASTER IDE's communication settings, specifically showing how to configure the serial port (RS232) and baud rate for connecting to the development board.

Description of Figure 11: Safety example FMSTR application. This screenshot shows the FreeMASTER application interface during runtime, displaying various safety test results and their status (e.g., CPU control test, clock test, DIO test, AIO test).

Description of Figure 12: Using output HEX file with calculated CRC in MCUXpresso IDE. This image illustrates the Debug Configurations dialog in MCUXpresso IDE, specifically the Startup tab, where the HEX file with calculated CRC is specified for loading during debugging.

Chapter 5 Running example

For the first run of the example on your hardware, it is recommended to turn off Flash, WDOG, Clock, AIO, and DIO test. In the next step, turn on step by step. When the WDOG is turned off and a safety error happens, the example stays in an endless loop.

5.1 FreeMASTER monitoring

FreeMASTER is used as the external PC tool for real-time monitoring. FreeMASTER is also implemented in the IEC60730B safety examples. For simplicity reasons, the MAP file is the source of the variable address. Before connecting FreeMASTER to your application, make sure that the application is running.

Running FreeMASTER:

Download and install FreeMASTER from www.nxp.com/freemaster.

The example project is in the safety.pmp file. Open it.

Check the project settings for your application:

IAR IDE and ARM Keil IDE: Navigate to the boards/<your board>/demo_apps/safety_iec60730b/<compiler>/<debug or release>/*.out file.

MCUXpresso IDE: Navigate to the <workspace>/<project_name>/<Debug or Release>/<project_name>.axf file.

Open "Project ->Options ->Comm" and select a correct RS-232 connection and speed. The connection speed is in the safety_config.h file's "SERIAL_BAUD_RATE" macros. By default, this speed is set to 9600 bd.

Now you can connect to the development board by pressing "CTRL+G" or clicking the "GO" button.

Usually, the AIO test is a number of results oscillating between 0x0 and 0x704 (test passed and test in progress).

Chapter 6 IEC60730B tests

The library contains the following tests:

The following chapters describe each test with focus on the example application (debugging).

6.1 AIO test

The analog IO test procedure performs the plausibility check of the digital IO interface of the processor. The analog IO test can be performed once after the MCU reset and also during runtime.

There are three values tested in the application:

Ensure that the ADC peripheral is set up correctly before calling the AIO test. In some cases, it is necessary to connect this signal externally (by a wire) to the corresponding pin. The test is performed in a sequence, as defined in the safety_config.h file:

/* ADC test */
...
...
{
  {(uint32_t)ADC_MIN_LIMIT(0), (uint32_t)ADC_MAX_LIMIT(60)}, \
  {(uint32_t)ADC_MIN_LIMIT(ADC_MAX), (uint32_t)ADC_MAX_LIMIT(ADC_MAX)}, \
  {(uint32_t)ADC_MIN_LIMIT(ADC_BANDGAP_LEVEL_RAW),
  (uint32_t)ADC_MAX_LIMIT(ADC_BANDGAP_LEVEL_RAW)}
}
#define FS_CFG_AIO_CHANNELS_INIT {6, 5, 4} /* ADC Channels for V_refl, V_refh, bandgap */

An example of the setting is shown above. The "FS_CFG_AIO_CHANNELS_INIT" macro defines that the ADC channel 6 is tested first, with the limits corresponding to VrefL (GND). Channel 5 is tested next, with the limits of VrefH (VCC). Channel 4 is tested next, with the limits for the bandgap.

6.2 Clock test

The clock test procedure tests the oscillator frequency for the CPU core in the wrong frequency condition.

NOTE: The default clock setting from the SDK library is used in the example. For a real application, ensure that the reference clock source is not dependent on the primary (tested) clock.

6.3 CPU register

The CPU register test procedure tests all CPU registers for the stuck-at condition (except for the program counter register). The program counter test is implemented as a stand-alone safety routine. Some tests stay in an endless loop in case of an error, others return a corresponding error message.

6.4 DIO test

The Digital Input/Output (DIO) test procedure performs the plausibility check of the processor's digital IO interface.

NOTE: Make sure that the time between the "set" and "get" functions is sufficient for the GPIO peripheral speed.

6.5 Invariable memory test

The invariable (Flash) memory test provides a CRC check of a dedicated part of memory. This test is turned off by default in the safety_config.h file.

The test consists of the following two parts:

The post-build calculation is different for each IDE:

In the IAR IDE, the CRC is calculated by the IDE directly using the linker (see Options->Build Action). The Flash test is fully integrated to the example project in the IAR IDE. It is necessary only to turn this test on in the safety_config.h file.

In the Arm Keil IDE, it is necessary to use a third-party tool (Srecord):

In case of an issue, check the following settings:

In the MCUXpresso IDE:

Create the "debug configuration" for your debbuger.

Open the "Debug Configurations" menu ("Run->Debug configuration") and select the "Startup" tab. In this tab, select "Load Image -> Use File -> <YOUR_BOARD>_safety_iec60730b_crc.hex".

This edited HEX file is located in the <workspace>/<your_project>/Debug/<your_project>_crc.hex folder.

NOTE: When you debug your application with the Flash test turned on, be careful when using the breakpoint. The software breakpoint usually changes the CRC result and causes a safety error.

6.6 Variable memory test

The variable memory on the supported MCU is an on-chip RAM. The RAM memory test is provided by the MarchC or MarchX tests. The test copies a block of memory to the backup area defined by the linker. Be sure that the BLOCK_SIZE parameter is smaller than the backup area defined by the linker.

NOTE: This test cannot be interrupted.

6.7 Program counter test

The CPU program counter register test procedure tests the CPU program counter register for the stuck-at condition. The program counter register test can be performed once after the MCU reset and also during runtime.

NOTE: The program counter test cannot be interrupted.

6.8 Stack test

This test routine is used to test the overflow and underflow conditions of the application stack. The testing of the stuck-at faults in the memory area occupied by the stack is covered by the variable memory test. The overflow or underflow of the stack can occur if the stack is incorrectly controlled or by defining the "too-low" stack area for the given application.

NOTE: Choose a correct pattern to fill the tested area. This pattern must be unique to the application.

6.9 Watchdog test

The watchdog test provides the testing of the watchdog timer functionality. The test is run only once after the reset. The test causes the WDOG reset and compares the preset time for the WDOG reset to the real time. For this test to run correctly, it is necessary to keep the WDOG_backup variable in a part of memory which is not corrupted by the WDOG reset.

NOTE: Some debuggers do not allow the WDOG reset. Due to this, it is necessary to turn off the WDOG when debugging the application.

How To Reach Us

Home Page: nxp.com

Web Support: nxp.com/support

Information in this document is provided solely to enable system and software implementers to use NXP products. There are no express or implied copyright licenses granted hereunder to design or fabricate any integrated circuits based on the information in this document. NXP reserves the right to make changes without further notice to any products herein.

NXP makes no warranty, representation, or guarantee regarding the suitability of its products for any particular purpose, nor does NXP assume any liability arising out of the application or use of any product or circuit, and specifically disclaims any and all liability, including without limitation consequential or incidental damages. "Typical" parameters that may be provided in NXP data sheets and/or specifications can and do vary in different applications, and actual performance may vary over time. All operating parameters, including "typicals," must be validated for each customer application by customer's technical experts. NXP does not convey any license under its patent rights nor the rights of others. NXP sells products pursuant to standard terms and conditions of sale, which can be found at the following address: nxp.com/SalesTermsandConditions.

While NXP has implemented advanced security features, all products may be subject to unidentified vulnerabilities. Customers are responsible for the design and operation of their applications and products to reduce the effect of these vulnerabilities on customer's applications and products, and NXP accepts no liability for any vulnerability that is discovered. Customers should implement appropriate design and operating safeguards to minimize the risks associated with their applications and products.

NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, COOLFLUX, EMBRACE, GREENCHIP, HITAG, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE CLASSIC, MIFARE DESFire, MIFARE PLUS, MIFARE FLEX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TRENCHMOS, UCODE, Freescale, the Freescale logo, AltiVec, CodeWarrior, ColdFire, ColdFire+, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert, QorIQ, QorIQ Qonverge, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine, Tower, TurboLink, EdgeScale, EdgeLock, eIQ, and Immersive3D are trademarks of NXP B.V. All other product or service names are the property of their respective owners. AMBA, Arm, Arm7, Arm7TDMI, Arm9, Arm11, Artisan, big.LITTLE, Cordio, CoreLink, CoreSight, Cortex, DesignStart, DynamIQ, Jazelle, Keil, Mali, Mbed, Mbed Enabled, NEON, POP, RealView, SecurCore, Socrates, Thumb, TrustZone, ULINK, ULINK2, ULINK-ME, ULINK-PLUS, ULINKpro, µVision, Versatile are trademarks or registered trademarks of Arm Limited (or its subsidiaries) in the US and/or elsewhere. The related technology may be protected by any or all of patents, copyrights, designs and trade secrets. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks licensed by Power.org.

© NXP B.V. 2020. All rights reserved.

For more information, please visit: http://www.nxp.com

For sales office addresses, please send an email to: salesaddresses@nxp.com

Date of release: 12/2020

Document identifier: IEC60730BIMXRT10XXEUG

PDF preview unavailable. Download the PDF instead.

IEC60730BIMXRT10XXEUG AH XSL Formatter V7.0 MR3 for Windows (x64) : 7.0.4.45923 (2020-07-14T10:31 09) Antenna House PDF Output Library 7.0.1600

Related Documents

Preview NXP i.MX RT10XX Safety Example User's Guide
This user's guide provides detailed instructions for setting up hardware, understanding the file structure, and running the IEC60730B safety library example application on NXP's i.MX RT10XX microcontrollers. It covers various safety tests and configuration details for embedded system developers.
Preview NXP LPC845 Breakout Board User Manual
User manual for the NXP LPC845 Breakout board, detailing its features, setup, usage with MCUXpresso IDE and third-party tools, debug probe functionality, and board layout for prototyping with LPC84x MCUs.
Preview FreeMASTER for Embedded Applications User's Guide
This user's guide describes the FreeMASTER application developed by NXP Semiconductors for controlling embedded applications using a graphical environment on a PC. It covers installation, features, usage, and online community resources.
Preview MCUXpresso Config Tools Quick Start Guide
A quick start guide for NXP's MCUXpresso Config Tools, covering introduction, tool selection, code generation, and revision history. This guide helps users configure NXP Cortex-M processors and generate initialization SDK-drivers.
Preview NXP MCXA15x: Continuous SRAM Address Usage and Configuration
This application note from NXP Semiconductors explains how to configure and use the SRAM X0 Alias feature on MCXA15x microcontrollers to achieve a continuous SRAM address, detailing memory maps, architecture, limitations, and workarounds for various IDEs like MCUXpresso, IAR, and Keil.
Preview NXP FRDM-MCXA156 Development Board: Quick Start Guide for MCUXpresso
Get started quickly with the NXP FRDM-MCXA156 development board. This guide covers setup, software, expansion boards, and support for the MCUXpresso Developer Experience.
Preview Get Started with the NXP FRDM-MCXN947 Development Board
A comprehensive guide to developing projects on the NXP FRDM-MCXN947 Development Board, covering connectivity, graphics, machine learning, motor control, and sensors.
Preview FreeMASTER for Embedded Applications User Guide
User guide for NXP's FreeMASTER, a real-time debug monitor and data visualization tool for embedded applications. Covers features, installation, usage, and communication protocols.