Embedded module TQMa117xL
STKa117xL Overview
The STKa117xL provides a powerful evaluation and prototyping platform using i.MX RT1170 MCU family from NXP.
The BSP is based on NXP’s MCUXpresso SDK, the build host setup instructions and BSP sources are provided via GitHub.
Please see the MBa117xL.SW.MCU.BSP.0001 repository for further instructions.
A list of supported example applications is available in the BSP repository.
Serial Port Configuration
Setup Serial Port
Settings | Value |
---|---|
Speed | 115200 |
Data | 8 bit |
Parity | none |
Stop bits | 1 bit |
Flow control | none |
The settings on the right have to be set in the terminal program of your choice in order to be able to use the the examples correctly.
We suggest TeraTerm.
For TeraTerm, click Setup → Serial Port
When connecting the STKa117xL to the host PC, two COM interfaces will show up.
Supported Applications
Application Overview
The MBa117xL supports the following applications:
Application | Purpose |
---|---|
AFE | Demonstrates the Analog Front End (AFE) capabilities |
Digital IO | Illustrates basic functions of the port expander |
EEPROM | Illustrates the usage of the EEPROM M24C64 |
Ethernet QOS | Demonstrates Ethernet communication features |
Ethernet 1GBs | Demonstrates Ethernet communication features |
FlexCAN | Shows the functionalities of the Flexible Controller Area Network (FlexCAN) |
GPIO LED | Demonstrates General-Purpose Input/Output (GPIO) with LED control |
“Hello World” | Basic “hello_world” demonstration |
IoT | Showcases IoT module BG95-M4 |
PMIC | Demonstrates PMIC functionalities |
RS485 | Demonstrates operations over RS-485 communication standard |
RTC | Shows built-in RTC's functionalities |
SD-Card | Demonstrates reading from and writing to a Secure Digital (SD) card |
SE97BTP | Showcases possible operations with the temperature-sensor and EEPROM SE97BTP |
SPI-Flash | Demonstrates SPI flash memory (MX25R1635F) operations |
USB | Demonstrates USB communication features |
Display-DSI | Demonstrates DSI display feature |
Each demo includes a README with more detailed information, including its purpose, preparation steps, and expectations when running the demo.
Build System
Structure of Repository
The general structure is constituted in such a way that it was tried to create as little maintenance effort for the demo repo as possible. Thus, everything that can be summarized in higher-level folders is also deposited there.
Folder/File | Description |
---|---|
templates |
Examples for the VS-Code setting files. |
templates/cmake-variants.yaml |
The Build-Type configurations. |
templates/settings.json |
Configurations for CMake and the cortex-debug tool. |
templates/launch.json |
All debug configurations. |
examples |
Path for the demo applications. |
examples/board |
Generic files used for every app and board-specific information/configuration. |
examples/board/cmake |
CMake related files used for integrating the board into the build system. |
examples/board/<file>.mex |
Configuration file used in MCUX-Config Tools. |
build |
All build-related files. |
build/boards/<boardtype>/dist |
Location for images. |
cmake |
Location for CMake scripts. |
dependencies |
Dependencies and dependencies related files. |
dependencies/TQDevices |
Custom programmed APIs used for the applications. |
dependencies/mcuxsdk |
The downloaded repository from NXP. |
dependencies/replace_include_guards.py |
A patch script for the mcusdk. |
doxy |
Doxy-file generator configurations. |
scripts |
Scripts for automated build tests and version generation. |
The build system was created based on the specifications of NXP. Accordingly, for each app in NXP's repo,
all sources from the Driver-APIs and other libs are added to the target named MCUX_SDK_PROJECT_NAME
using the target_sources()
command. This target is created in the CMakeLists.txt
from the application.
This scheme is basically also used in this repo. However, all Include-Guards were changed from Global to
Directory using the patch script replace_include_guards.py
. This has the consequence that
one build directory can now be used for all apps here. Using the add_subdirectory()
command, a directory is added per level, so that there are no conflicts per target.
However, this has the disadvantage that the order of all includes must be correct.