Forum - Recent Threads

Smart Spaces Design Challenge - Winners Announcement

JoRatcliffe — Fri, 05 Dec 2025 11:55:39 GMT

Hi everybody, it’s time to announce our latest design challenge winners – our Smart Spaces winners!

First, let’s take a quick look back at the prizes and the competition details.

The Prizes
Prizes are subject to change but will be of similar price and style.

Prize	Prize Category
Grand Prize Winner and Runner Up	Approximate Value $1160 USD* Nest Home Automation kit, Google Nest CCTV and Doorbell set.
Finisher Prize** To be a finisher you must complete 5 blogs and show us testing the resilience of their project.	Approximate Value $30 USD* MultiComp Pro Multimeter Set

Prize

Prize Category

Grand Prize Winner and Runner Up

Approximate Value $1160 USD*

Nest Home Automation kit, Google Nest CCTV and Doorbell set.

Finisher Prize**

To be a finisher you must complete 5 blogs and show us testing the resilience of their project.

Approximate Value $30 USD*

MultiComp Pro Multimeter Set

*Or local equivalent
**Grand Prize and Runner Up winners will also earn the finisher prize.

The Challenge
For the chance to win one of the prizes above, Challengers were tasked with using an NXP FRDM MCX A and an N Series (A15X) to create a building automation project. Projects that contained the most creative prototype – along with posts that were media-rich – would be viewed more favorably in the judging process.

Now, it’s time to reveal the winners:

Grand Prize Winner
Adaptive Environmental Monitoring and Smart Access Control

skruglewicz designed an intelligent building automation solution using a distributed architecture, with the NXP FRDM MCX A153 as the central hub and multiple FRDM MCX N236 boards as edge sensor nodes.

Runner Up
Destination Dispatch Elevators

balajivan1995 created an elevator system for optimizing usage to reduce the inefficiencies and crowding inherent in traditional elevator systems.

Congratulations to our winners! A big shout-out as well to our design challenge finisher!

Finisher
TinyML enabled Low Power Exhaust Fans for Smart Buildings

yamanoorsai made a prototype smart exhaust fan that adjusts its speed based on the building's air quality for applications such as 3D printer farms and crowded rooms, where air quality can fluctuate.

E14Alice will be in touch to arrange the shipment of the prizes 🎁

A big thanks to everyone who participated, contributed and discussed during the design challenge, and thank you also to NXP for their support.

Finished publishing my project

yamanoorsai — Tue, 02 Dec 2025 17:24:08 GMT

I am a day late but I did finish documenting my work so far. I would like to thank everyone for the opportunity to road test the MCX series development board. It has been a learning experience and documenting your project in any state goes to show what you have accomplished so far and the work left in your project. It has certainly been an eye opener.

DDS Elevator - Measuring up

balajivan1995 — Mon, 01 Dec 2025 12:50:18 GMT

Introduction
TOF sensor
Interfacing multiple TOF sensor
Using ESP32 for interfacing with i2c
Failed Communication attempts
- SPI interface
- CAN interfacing
Conclusion

Introduction

Once the elevator starts moving, we need to know at which point the elevator should land and for that we need to measure the distance of the elevator from a fixed point. Since we will be designing for three elevators that will run side by side, we should aim to reduce the number of wirings as well. In this post, I will cover how we are going to measure the distance and the sensor arrangement.

TOF sensor

Typically, we could use Ultrasonic sensor, but I felt they are slightly bulky for this project and it needs a separate 5v for each node. So, I decided to use ToF sensors. ToF sensors are lot smaller, consumes less power and can be operated over I2C.

ToF sensors works in a way similar to ultrasonic sensor, except it measures the time it takes for IR/light to strike the target and reflect back.

In this project we will be using a VL530x based ToF sensor which can measure up to 200cm. We just need the sensor to read the distance accurately up to 40cm.

Interfacing multiple TOF sensor

Since we need 3 ToF sensors, we can’t interface them all directly we won’t have enough FlexComm peripheral for UART. So, I decided to use an I2C multiplexer. Using which we can connect up to 8 I2C devices.

My initial plan was to interface the I2C multiplexer with A153 board, unfortunately I could not establish the I2C communication between them. I have tried to port different libraries available, but none of them seemed to work.

Using ESP32 for interfacing with i2c

Since I have already planned to use ESP32 to transmit lift telemetry, I have decided to expand the scope of ESP32 by interfacing it with ToF sensors and transmit the distances to N236 board using UART.

community.element14.com/.../tof_5F00_reading.webm

Failed Communication attempts

SPI interface

Even though I know it will take lots of wiring, I decided to give a try for SPI communication between N236 (master) and A153 (slave) boards. Although I could get the communication working between them, there was a lot of workarounds and required master to initiate the conversation always. Which became a bothersome point, I decided to drop A153 altogether. N236 is powerful enough to do the work of A153 board which originally just required monitoring sensors and GPIOs.

CAN interfacing

N236 board comes with a CAN transceiver. Since ESP32 supports CAN communication, I wanted to interface them together. I was actually surprised to see that I could recreate the "LoopBack example" provided by NXP. Unfortunately, I ran into issue with ESP32 this time. ESP32 has introduced some breaking changes with their latest release and my old which I used as reference started throwing multiple build errors. At the end, I decided to keep the communication simple and decided to go with UART interface.

Conclusion

This is my final forum post. So far, we have seen how the boards work, what are all the issues I have faced, and how to mitigate them. Throughout these trials and errors, I have to make changes in the original architecture I planned and adapt according to the new issues. In the last project article, we will conclude with our final demo model.

Writing up my project report

yamanoorsai — Mon, 01 Dec 2025 08:38:02 GMT

I have gotten all the components working and working on writing the project report. I am just returning from the Thanksgiving holiday. To avoid violating the challenge requirement, I am thinking of submitting my draft as-is and continue editing my project.

Will this work? I have no illusions that I am going to win the contest. I just want to document my work so far.

Smart Spaces - Using RT-Thread with FRDM- MCXA153

fyaocn — Wed, 26 Nov 2025 01:15:29 GMT

1 Brief on RT-Thread

RT-Thread (Real-Time Thread) is an open-source, embedded real-time operating system (RTOS).

Its key differentiator is that it's not just a minimal kernel but a complete platform, offering a wide range of middleware components and a package management system, making it highly scalable for a broad spectrum of IoT applications, which allows for rapid prototyping and development of feature-rich IoT devices without the need to integrate and maintain numerous third-party libraries. It effectively bridges the gap between a simple RTOS like FreeRTOS and a full-featured OS like Linux.

2 Develop with SCons and Virtual ENV

Developing with the RT-Thread env environment and SCons is the standard and recommended way to build RT-Thread projects.

env(RT-Thread env tool): This is a powerful auxiliary tool provided by RT-Thread. It's not just a command-line interface; it's an environment that contains the package manager (pkgs) and a collection of Python-based build and configuration scripts. It's the primary tool you interact with for project configuration.
SCons: This is an open-source build system, written in Python. It is the underlying engine that RT-Thread uses to compile source code, manage dependencies, and generate the final binary (like rtthread.elf, rtthread.bin). You describe the build process in a Python script called SConstruct.

Download the rt-thread package from github and start the env

upgrade packages automatically,

Here is the code main.c

#include <rtdevice.h>
#include "drv_pin.h"

#define LED_PIN        ((3*32)+12)

int main(void)
{
#if defined(__CC_ARM)
    rt_kprintf("using armcc, version: %d\n", __ARMCC_VERSION);
#elif defined(__clang__)
    rt_kprintf("using armclang, version: %d\n", __ARMCC_VERSION);
#elif defined(__ICCARM__)
    rt_kprintf("using iccarm, version: %d\n", __VER__);
#elif defined(__GNUC__)
    rt_kprintf("using gcc, version: %d.%d\n", __GNUC__, __GNUC_MINOR__);
#endif

    rt_pin_mode(LED_PIN, PIN_MODE_OUTPUT);  /* Set GPIO as Output */
    rt_kprintf("MCXA153 HelloWorld\n");

    while (1)
    {
        rt_pin_write(LED_PIN, PIN_HIGH);    /* Set GPIO output 1 */
        rt_thread_mdelay(1000);               /* Delay 500mS */
        rt_pin_write(LED_PIN, PIN_LOW);     /* Set GPIO output 0 */
        rt_thread_mdelay(500);               /* Delay 500mS */
        rt_kprintf("MCXA153.\n");
    }
}

Other Key files in the project

SConstruct: The main SCons build script. It sets up the global environment and includes other scripts.
SConscript: Found in subdirectories (like libraries, packages). They define how to build the files in that specific directory.
rtconfig.h: The C header file generated by menuconfigcontaining all your #defines.
.config: The saved configuration for menuconfig.
rtconfig.py: Contains Python variables for the compiler toolchain (e.g., EXEC_PATHfor the GCC toolchain location).
packages/: The folder where pkgs --updatedownloads all the online software packages.

3 Build the project with scons

Build the project with scons

output the rtthread.efg

4 Flash the board

Flash the board, use pyocd since the MCU-Link is CMSIS-Dap compatible,

Now it is ready to restart the board for result.

5 Run with the blinky

Here is the result.

DDS Elevator - Enabling LPUART in N236 board for Serial communication

balajivan1995 — Tue, 25 Nov 2025 17:55:20 GMT

Introduction
Pin Configuration
Clock
Peripheral
Transfer Method
Callback
Modifying Driver code
Configuring Read Non-blocking function
Output
Conclusion

Introduction

Since configuring UART is slightly complex and there is no proper tutorial on how to configure multiple UART to use and receive in a non-blocking manner, I have decided to write this blog to help others who might be in need of this. For this example, we will enable the default UART and the UART pins connected in the Micro Bus extension.

Pin Configuration

Peripheral	Rx Pins	Tx Pins
Default	P1_8	P1_9
MicroBus	P4_2	P4_3

Clock

We will use 12Mhz clock for both FC2 and FC4. From the clock page, activate clocks for both FlexComm peripherals.

Peripheral

We are not going to use DMA or RTOS, we will use the basic Device specific driver for this.

Transfer Method

Instead of polling method, we will use transfer method which is versatile and can be used either in blocking mode or as non-blocking mode.

We can capture more bytes at a same time, but it’s hard to know the amount of received data. Let’s say for example, we want to receive 10 bytes as default, and we receive only 5 bytes, the rx buffer will receive the minimum of both size which is 5 bytes, but we won’t know this detail when call back is triggered. So, for this example, we will receive one byte at a time.

Callback

Unless we configure the callback, we will have to rely on the return statement of

LPUART_TransferReceiveNonBlocking

function which is not reliable in knowing how many bytes we have in our buffer. Lets enable the callback and give the name as "cb_rx".

These are the configurations we need to get UART receive in non-blocking mode. Now select "Generate Code". Once the code is generated, try to build the application. It will throw error as we have not defined what our callback function does.

void cb_rx(LPUART_Type *base, lpuart_handle_t *handle, status_t status, void *userData)
{
	if(status == kStatus_LPUART_RxIdle && base == LP_FLEXCOMM4_PERIPHERAL)
	{
		LPUART_WriteBlocking(LP_FLEXCOMM4_PERIPHERAL, LP_FLEXCOMM2_rxBuffer,1);
	}
}

Add this code in main c file. Now the build will succeed. What we are trying to do is, on receiving the callback, we will print the first character stored in our receive buffer using default UART.

Modifying Driver code

Since we are using I2C pins which can be configured as Rx/Tx pins of FC2, we need to ensure the UART is properly initialized. Unfortunately, the driver code automatically doesn't take care of this, and we need to make some manual changes in the fsl_lpuart.c in the LPUART_Init function.

    	if(base==(LPUART_Type *) LP_FLEXCOMM2_BASE)
    	{
    		status = LP_FLEXCOMM_Init(LPUART_GetInstance(base), LP_FLEXCOMM_PERIPH_LPI2CAndLPUART);
    	}
    	else
    	{
    		status = LP_FLEXCOMM_Init(LPUART_GetInstance(base), LP_FLEXCOMM_PERIPH_LPUART);
    	}

Configuring Read Non-blocking function

For this example, we will connect the Tx of FC2 to Rx of FC2 so we will verify the working by using this loopback setup. We will transmit test data every 1s and check whether we are receiving the same.

To get the callback the read non-blocking repeatedly.

void testData()
{
	static uint32_t prevCounter = 0;

	if( ms - prevCounter > 1000 )
	{
		prevCounter = ms;
		LPUART_WriteBlocking(LP_FLEXCOMM4_PERIPHERAL,(uint8_t *)"TestData\n", 9);
	}
}

    while(1)
    {
    	testData();
    	(void)LPUART_TransferReceiveNonBlocking(
    			LP_FLEXCOMM2_PERIPHERAL, 	// MicroE extension uart
				&LP_FLEXCOMM2_handle,		// FC2 Transfer Handle
				&LP_FLEXCOMM2_rxTransfer,	// FC2 Receive buffer details;
				&receivedBytes				// dummy variable. No idea what it actually does
				);
    }

Output

Now, build and flash the firmware in the N236 board. Open the serial terminal and we will see "TestData" printed every one second.

Conclusion

Although this is not in my intended list of forum post, I want to keep this process documented so that it will be useful for anyone who is facing the same issue.

Configuring LPUART on MCXN236 - A frustrating experience

yamanoorsai — Sat, 22 Nov 2025 07:18:40 GMT

I used the SDK examples to configure LPUART with my MCXN236 project. I think there is a bug in Flexcomm initialization inside LPUART_Init(). LPUART_Init() is auto generated by the SDK.

I was not able to get LPUART working when Flexcomm was initialized as follows inside LPUART_Init():

status = LP_FLEXCOMM_Init(LPUART_GetInstance(base), LP_FLEXCOMM_PERIPH_LPUART);

I was able to get it working when I configured it as follows:

status = LP_FLEXCOMM_Init(LPUART_GetInstance(base), LP_FLEXCOMM_PERIPH_LPI2CAndLPUART);

What might be the reason for this?

DDS Elevator - Bit of human touch

balajivan1995 — Mon, 17 Nov 2025 12:55:32 GMT

In every elevator, there is an option for the user to select which floor they want to travel to. In case of DDS elevators, there will be feedback which immediately shows which elevator was assigned to them. In this blog, we will see how to interface human interaction between our lift model to our microcontroller through the use of HMIs. We will also cover the struggles it took to get the concept working.

Why HMI
Struggling with setting up multiple UART
Scalability issue
- Initial idea
- Daisy chaining
Programming the HMIs
Conclusion

Why HMI

HMI provides a way for humans to provide their input and receive feedback immediately. While I could simplify the process using buttons for inputs and LEDs for feedback, it will include using lots of GPIOs and way too many wirings.

Imagine for a single floor, we need 4 buttons to get user input on floors, 1 RGB led with different light configuration for different statuses. That makes each floor requiring 5 GPIOs. Now, for our lift model, we have 4 floors and that makes 16 buttons to get user input and 4 RGB LEDs. We could reduce the number of GPIOs required by 4*4 matrix keyboard and bit addressable RGB LEDs. That still requires up to 9 GPIOs.

Now, HMIs on the other hand, depending on the model can be operated by using just UART alone. That’s just 2 GPIOs for one floor, 8 GPIOs for 4 floors. Since it is a touch supported HMI, we could get user input and provide feedback on display.

For this project we will use a 2.8” touch display from Nextion Brand. It is a resistive touch display and cheaper.

Struggling with setting up multiple UART

Initially I wanted to use FRDM MCXA153 to control the HMI but when I tried to enable the second UART, it stopped working. So, I moved to MCXN236 board. Even there I faced similar issues. There is a UART port exposed as a Micro Bus expansion, which didn’t work as well. Luckily MCXN236 has multiple UART ports and one of them is exposed in the LCD header. On configuring that particular port, second UART was up and running.

Scalability issue

Since we have finalized to use 4 HMIs, we need to look for ways to minimize the number of wires. Each HMI comes with 4 pins – Vcc, Gnd, Rx, Tx. Supply and ground wires can be taken parallelly from a power source. But we still need to route 8 wires for UART.

Initial idea

My initial horrible plan was to make use of multiple MCUs each reporting back to MCXN236 board. MCXA153 has one extra UART port, ESP32 has 2 extra UART ports, and with one already working UART from MCXN236 combining all these resources we could wire something like this.,

Just looking at the above block diagram made it obvious this is a ridiculous way of connecting multiple HMIs, so I dropped this idea and decided to try an alternative.

Daisy chaining

Daisy chaining is a simple interface method where we connect multiple nodes in a linked list manner. I got this idea from Ethercat communication which uses two ethernet port, one will act as input and other as output.

The Ethercat master will send a process image, with request to fill the process image with data from slaves or update the slaves from the process image. By slightly modifying this for UART, we can use Tx as output port and Rx as input port.

Programming the HMIs

Nextion provides an application called “Nextion Editor” which can be used to design the UI. It also provides simulation mode to immediately visualize the changes.

Since steps to cover how to program an HMI display out of topic for this post, I will add few links in reference.

UI – Dynamic Floor selection

Instead of programming each HMI display with a different identification number, I have decided to create a configuration page where the floor in which display will be placed can be selected.

Values start with 0 for button 1, 1 for button 2 and so on. For example, on pressing the number 4, the value “3” will be written to memory ().

wepo 3,10

wepo is the write to EEPROM memory command, 3 is the identification for 4^th floor and 10 is the address we are writing to.

On pressing the home icon, the HMI will restart. On initializing, it will read from memory address 10 and store the floor value in a variable for further use.

repo liftID.val,10

repo is the read from EEPROM memory command to read from the memory address 10 and store into variable called “liftID”.

UI – Getting user input

The HMI has few a variable initialized to “0xff” value. When user press a button, HMI will update the internal value like this. There is a timer which monitors the variable, once it detects the value is not “0xff”, it transmits the current value to next node and reset back to “0xff”.

Button value = Floor ID * 10 + Selected Floor num.

Example, if a user press button labelled 2 on 2^nd floor, it will be saved as 32. The HMI will transmit the value as “but.val=32” which will update the variable of next node, and the process will continue until the message reaches the MCU.

Below is the screen record of the HMI logic in a simulator.

community.element14.com/.../button_5F00_press.mp4

UI – Feedback response from microcontroller

There are two types of feedback.

Whether the elevator will go up, down, or rejected on pressing the button.
Which elevator to select.

The message format is similar to getting input from user. There will be a commonly named variable which will be updated and passed on until it reaches the correct end node.

community.element14.com/.../feedback.mp4

I have created a simple code to check whether the logic works when used with MCXN236. Below are the videos I took when I tried to control only one HMI and with two HMIs. I am glad to find after all these ordeals, I got it working.

community.element14.com/.../single.mp4

community.element14.com/.../multi.mp4

Conclusion

To be honest, neither the HMI UI design nor daisy chaining multiple UART is not the difficult part. I have worked with various HMIs, and I could set it up with MCUs from ST or Espressif without much difficulty. What I didn’t expect was how difficult it will be to enable a second UART in MCXN board and make it usable. This is slightly disappointing as I want to use one instance of most of the communication peripheral in that board. Anyways, we will see how to establish communication between MCXA and MCXN board in the upcoming post.

References

1. https://nextion.tech/instruction-set/

2. Nextion Displays - YouTube

Switched from MCXA153 to MCXN236

yamanoorsai — Sun, 16 Nov 2025 08:38:47 GMT

I had to move my project from MCXA153 to MCXN236 for two reasons.

The sensor I was using came with a closed-source static library. The library required a 4K memory allocation on the stack that was breaking things. I tried increasing the stack but there was also heap usage from libc for printf operations. I did a delicate dance trying to adjust the stack/heap limits but I just had to give up at the end. While it is a simple sensor, I couldn't get going with a 32K RAM. I couldn't get use the sensor without the library.
I tried using another sensor but I had to give up due to floating point operations. This sensor also came with a closed source static library.

I got away with switching the microcontroller. Onwards to trying to get other components going.

NO connection to chips debug port on the MCXN236?

skruglewicz — Sat, 15 Nov 2025 02:26:23 GMT

I’m still having problems with the MCXN236 . Can't find the probe

CONSOLE log:

LinkServer RedlinkMulti Driver v25.6 (Jun 26 2025 19:34:05 - crt_emu_cm_redlink build 1017)
Found chip XML file in C:/nxp/workspace/frdmmcxn236_hello_world/Debug\MCXN236.xml
( 5) Remote configuration complete
Reconnected to the existing LinkServer process.
Connecting to probe 2 core 0 (using server started externally) reports:
'Ee(42). Could not connect to core.'
Retrying...
Reconnected to the existing LinkServer process.
Server OK but no connection to probe 2 core 0 (after 3 attempts) - Ee(42). Could not connect to core.
Failed on connect: Ee(42). Could not connect to core.
No connection to chip's debug port

I'm dead in the water with the MCXN236 and can not develop my project without it Does any one know why thus is happening? Is my board defective?

any help here would be appreciated.

Thanks

Steve K

Configuring LPTMR0 on MCXA153

yamanoorsai — Fri, 07 Nov 2025 17:12:52 GMT

I am trying to configure LPTMR0 for a 1-second interval. I followed the lptmr example in the SDK examples to configure my timer. The interval at which the interrupt is generated never correct.

Here are the steps I followed:

Configure the LPTMR0 clock source to 96MHz with a divider of 16. The clock frequency for LPTMR0 is 6MHz.
After code generation, I set the timer count to 6,000,000 for 1 second interval.

I confirmed that the timer is a 32 bit timer. The timer does work but the interval duration is not 1 second. It is something else.

Did I skip a step in configuring the timer?

Smart Spaces - NXP eIQ Time Series Studio on MCXN236 and There is a fault

fyaocn — Wed, 05 Nov 2025 02:42:40 GMT

1 Create Motor fan state project in NXP-Eiq

With 3-axis sensor on FRDM-MCXN236, to train and deploy a machine learning model for a predictive fan state application

Fan States:

FAN-Off — The fan is turned off.
FAN-On — The fan is turned on and running in a normal condition.
FAN-Clogged — The fan is turned on and the airflow is obstructed.
FAN-Friction — The fan is turned on and excessive friction or a blade fault is detected.

2 Training

Add data in csv file

Each sample window comprises original signals from the three channels (ax, ay, az) of an accelerometer. There are 128 sampling points in each channel, totaling 3 * 128 = 384 float data points. Each sample time window is written as one line.
Data format: x0 y0 z0 x1 y1 z1…, separated by spaces.

Then start training

3 Emulating

The model during training can be emulated to validate it.

4 Generate code

If the value is OK. Then generate the code.

This code comes with read-only library file and one header file in .h. This can reduce time to code and it limit the model selection as well.

5 Generate code and download

After the process , there is problem. The On-board MCU-Link is missing, and cannot be downloaded to the FRDM -MCXN236 board.

Try many time, still can not probe and recover the port. Really hard time for this project.

Before figure out what to do. Try more times for new wayout.

Detecting devices on the I2C bus

yamanoorsai — Tue, 04 Nov 2025 15:24:31 GMT

It has been quite a journey and I am making progress at snail's pace. While the SDK is shipped with a lot of examples, it is somewhat difficult to find requisite information.

I wanted to perform a scan of the I2C bus to detect devices. I got it working but I was not able to get the driver working.

The I2C bus scanner didn't work either. It turns out that the I2C devices needed a reset.

Onward to integrating the driver again.

DDS Elevator - Hello World!!!

balajivan1995 — Wed, 29 Oct 2025 15:11:36 GMT

First Impressions
- FRDM A153 board
- FRDM N236 board
Software and SDK
Test Projects
Thumbs up for
Thumbs down for
Quick links
Conclusion

First Impressions

The boards are of really good quality. Offering much processing power, expandable headers, these boards could be used as a drop-in replacement for Arduino Uno boards (We will talk about library support later). Each board comes with its own USB C cable to power up the boards, hopefully we will be able to drive more power using USB C connection.

FRDM A153 board

A153 board operating at a modest 96mhz is packs more peripheral compared to similar priced microcontrollers. But most of the peripherals are not exposed to keep the Arduino form factor.

community.element14.com/.../a153.mp4

FRDM N236 board

N236 board operates at 150mhz, supports CAN transceiver, audio inputs (Audio Jacks are not soldered by default), LCD connector. Among the two boards, this is the bigger one with whole lot of peripherals and a huge add on flash memory.

community.element14.com/.../n236.mp4

Software and SDK

MCUXpresso

MCUXpresso is the dedicated IDE for MCUX series of microcontrollers from NXP. Like every other IDEs this is also a clone of Eclipse IDE. MCUXpresso looks like a rebranded LPCXpresso and comes prepacked with SDK for LPC microcontrollers. To be honest I lost track of all the IDEs NXP has for its broad range of microcontrollers and microprocessors (Kinestis, DS).

Creating a new project

We have an opening page where we select which controller or board we want to program.
One thing different compared to other mainstream MCU IDE, we will have to select our library for the peripherals before even selecting the pins.
NXP not only provides SDK, they also provide a HAL layer, device specific adapter, FREERTOS and CMSIS library as well.
The basic template has lots of drivers and libraries enabled by default which might feel a bit bloated, for example GPIO and UART adapter and a debug library are enabled by default.
Give the project a name and select finish to create the project.
Now comes the pin selection. You can select “Pins” tab and select the required pins or select pins which are grouped to a specific peripheral.
Once the pins are selected, we need to enable the clock for the peripheral. The peripherals are neatly organised and placed one after another. There is also a search option to look for the specific peripheral in case it’s hard to locate a peripheral among the lot. Enable the required peripheral.
Switch to “Component” view. From here we can select the driver for our required peripheral, if we have selected CMSIS from the welcome page, we can see it listed here as well. Select the required one and click generate code.
1. Component page offers a variety of ways to configure a peripheral when device specific component is selected and the SDK components can be modified anytime.
  1. Polling – Standard blocking way of sending/receiving data
  2. Interrupt – Standard interrupts set by using interrupt flags.
  3. Transfer – Provides blocking as well as non blocking API with support for interrupts
  4. DMA – for transferring huge amount of data faster, supports interrupts.
2. When CMSIS is selected, we see only two options mostly
  1. Interrupt
  2. DMA

Note on Arduino support

Unlike other mainstream controllers which has support for Arduino Core, MCX series doesn’t have Arduino support. The board has Arduino form factor headers, and Arduino compatible pins, but libraries available for Arduino needs to be ported.
If you are comfortable working with Zephyr, MCXN has a rich and steady support for Zephyr, I would say like Nordic Semiconductors they are also actively pushing for Zephyr + West build. (NXP is one of the six founding member of The Zephyr™ Project). Since setting up Zephyr and west on a windows laptop is a migraine inducing feat that stresses both my laptop’s storage and my patience, I decided not to go there unless I am left with no other option.

Test Projects

Since I am new to MCXA/MCXN NXP family of microcontrollers, I started by exploring the GPIOs and UART first.

LED Blink

MCXA153 board comes with a RBG LED and 3 push buttons (labelled as switches). We will see how to set/clear a GPIO as well as read input using polling mechanism.
We can see how NXP tried their best not to look like a copy of ST’s HAL library as well.
APIs to initialize a GPIO pin, perform set and clear operations on a GPIO Pin for ST range of MCU

void HAL_GPIO_Init(GPIO_TypeDef  *GPIOx, GPIO_InitTypeDef *GPIO_Init)
HAL_GPIO_WritePin(GPIO_TypeDef *GPIOx, uint16_t GPIO_Pin, GPIO_PinState PinState)

APIs to initialize a GPIO pin, perform set and clear operations on a GPIO Pin for NXP MCXN/MCXA

void GPIO_PinInit(GPIO_Type *base, uint32_t pin, const gpio_pin_config_t *config)
static inline void GPIO_PinWrite(GPIO_Type *base, uint32_t pin, uint8_t output)

Maybe I am used to ST’s version, using “GPIOx” makes more sense than “base”.

I have created a brief tutorial on how to use the GPIOs.

https://youtu.be/utMRGCzOVdk

Hello World

In this video I cover how to enable the pins for LPUART0 and how to send/receive message using polling mechanism.

https://youtu.be/EShPC0xfuBE

While we can use the blocking send function to send a message, using blocking receive is practically not at all useful as we won’t know exactly when we will receive a message. We will cover non-blocking receive in upcoming posts.

Timing and Delay

No Embedded project will be complete without using delays, be it either blocking or non blocking. MCX series provides us with Sysclock using which we can trigger an interrupt on nano second level.
Since we won't need that much accuracy and millisecond level timing is enough for most tasks, we will configure the sysclock to generate an interrupt every milli second.

SysTick_Config(96000000);

Copy the callback function and place it in main file.
static uint32_t ms = 0;
void SysTick_Handler(void)
{
    ms++;
}

uint32_t getMillis()
{
    return ms;
}


Since we shouldn’t hog the interrupt call back function, we will just increment a variable by 1 which will act as our timer, something similar to Millis() on Arduino or getMillis() on ST family.
For blocking delay, we will use the below function. You can refer the below code to see how to use the counter as both blocking and non-blocking delay.

void delay( uint32_t delayInMs)
{
    uint32_t currentTimeInMs = ms;
    while( ( ms - currentTimeInMs ) <= delayInMs )
    {
        ;
    }
}

void someFunc()
{
    static uint32_t prevTimer = 0;
    if( ( ms - prevTimer ) > 1000 )
    {
        prevTimer = ms;
        
        // Do something
    }
}

Thumbs up for

MCXN236 board provides a lot of power and several 5v/3.3v options. Meaning we can power our sensors, output devices directly from it.
If we select the board option in project create page, we can see the Arduino/MicroE interface showing up as an option to select the pins. Which helps us in narrowing the required pin as we know where it is located.
The Clock configuration is really smooth. Compared to some other Microcontroller IDEs which does some calculation based on user input, and sometimes not at all work properly, leaving new users confused (cough, STM32 cough), MCUXpresso lists preconfigured clocks that works well and selecting it is quite easy.
Whether to use a callback when some interrupt happens is entirely up to you. During the peripheral selection, we have the option to enable or not use callback.
Let's say, we need to make some changes in a peripheral, now before generating the code we have an option to compare our existing code with the newly configured code. This is a really good option that allows us to verify whether we are adding some feature unnecessarily or removing a required one.
Support for CMSIS library is really good as well, especially for some peripherals you just need a high-level library, and interrupts to know the job is done. Which is much better than combing through several implementations for the same peripherals.

Thumbs down for

There are some bugs that needs to be fixed in the IDE and mistakes in schematic. Below are the few I encountered.

There is no mild way for putting this nicely, if you select the default template to generate application, it will be bloated. Either you need to include everything from adapter, peripheral, common library to build an application that just blinks for a sec, or you will have to use their single header that has all the register you need to build from scratch. There is no in-between.
Let’s say, we are planning to create a new project with new board, if we open the configuration page for the new board while keeping the previous project open, it will throw an error saying “Microcontroller Not found”. We will have to close every other project and select the configuration page.
If you have previously configured the project to use CMSIS or Freertos, now want to remove or replace that component, after removing the previously selected components from Component page, if you try to build, it will throw error. Because the library files are still present in the components folder and needs to be manually removed.
Even though the peripheral tab should list all the pins that can be used for that particular peripheral, CAN1 TX/RX pins are not showing up here. But if we select the Pins tab and select the pins manually, we can see CAN1 TX/RX showing up there.
If you connect both boards at same time, it doesn’t automatically detect which one to flash. It will try to flash the first device it finds in LinkServer application.
There are some times when debugging straight up fails or the values are not getting updated properly.
These are all not a deal breaker in anyway, but this gets annoying when you have two boards and switching from one project to other or importing example projects to explore the peripherals.

Quick links

	MCXA153	MCXN236
Product Page	MCXA153	MCXN256
Schematic	MCXA153	MCXN256
Datasheet	MCXA153	MCXN256
Reference Manual	MCXA153	MCXN256
SDK reference	MCXA153	MCXN256

Conclusion

All in all, these boards are really worth for that price point. The MCXA153 is quickly becoming my favourite dev kit and I am excited to start interfacing all the modules together to finish my project.

PROBLEMS - Using MCUXpresso IDE with MCXA153 and MCXN236 on the same PC

skruglewicz — Thu, 23 Oct 2025 23:00:08 GMT

I'm currently working to run example code on both the MCXA153 and MCXN236 boards from the same instance of MCUXpresso IDE on a single PC. I wanted to share my experiences here, in case anyone else is attempting this during the challenge, Also, to offer a solution I found for one of the issues I encountered after struggling with the IDE for some time. There’s still another issue described at the end of this post that I’m having difficulty understanding.

I followed the instructions on the MCXA153 Build and Run page. On this page I learned:

To import an SDK example (like hello world) into MCUXpresso IDE.
The guide walks you through selecting the FRDM MCX board, expanding the demo_apps category, and choosing hello_world.
You’ll build the demo and set the debug console to UART for serial output.
Steps include connecting the board via USB MCU-LINK port, flashing the application, and selecting the MCU-Link CMSIS-DAP debug probe. NOTE – Be sure to include the
Instructions for opening a serial terminal (settings: 115200 baud, 8 data bits, no parity, 1 stop bit) are provided.
Finally, you will run the demo and see terminal output.

I tried the “hello world example” on both devices to get a feel for developing on two devices from the same IDE on the same PC. I followed the instructions from the “Build and Run Page” outlined above. I was able to get the example to run on the MCXA153 the first time, but unable to successfully run again after getting the following problem, trying to run it on the MCXN236

Problem:1: “no Terminal output”

Build
Debug
The following dialog appears to select a probe
1. I selected the MCU-Link CMSIS-DAP debug probe for the MCXN236:

I selected the MCU-Link CMSIS-DAP debug probe for the MCXN236:

Hint: the next time you run the code, this screen does not show. to allow it to show up again , simply delete the file "frdmmcxn236_hello_world LinkServer Debug.launch", in this case for the MCXN236. Now the dialog should come up on the debug session.

Open up a serial terminal to be able to see the application's output.

Problem: empty terminal?

What could be wrong?

Solution : I had the wrong Serial COM port selected. It needs to be the com port that the MCXN236 is connected to . In my case it is COM4.

Select the “Terminal” window and press the “new terminal” icon. Choose a “Serial Terminal” and then set the UART settings to 115200 baudrate, 8 bit data size, no parity and 1 stop bit. Press OK.

Oh now the mcxa153 project is also working . I need to select the correct SDK, debug probe port and set the serial port at the proper COM port, in ny case COM3.

Now the debugger is running but it hangs the code here after pressing a character on the screen?

NOW I’m stuck and pondering this second Problem:

Why is it printing 2 lines of “Hello World”?
Why is it paused at the line ch = GETCHAR();
What is it expecting from the function call GETCHAR()

I was wondering If any of the challengers have this problem or have an answer? For now I’ll be continuing to run other coding examples to keep experimenting with the IDE using 2 devices.

Happy coding

Smart Spaces Design Challenge - Deadline Extended by Two Weeks!

JoRatcliffe — Tue, 21 Oct 2025 15:59:05 GMT

Hey everyone, e14phil and myself are extending the due date for the Smart Spaces design challenge.

The new due date is midnight UK time on Monday 1st December. Winners will be announced on Friday 5th December.

Hope this helps give you the extra time you need for any extra discussion, project updates and final write-up!

We will update the dates in the competition group and T&Cs soon to reflect this.

Smart Spaces Design Challenge - Some Quick Guidance on Project Updates & Final Write-Ups

JoRatcliffe — Mon, 13 Oct 2025 15:31:57 GMT

Hey everyone, as we are now well into the build period I'm sure many of us are thinking about our final progress updates and end-of-project write-up, I thought it would be helpful to share some guidance and examples.

Originality, innovation, and technical merit all factor into the judging criteria for the challenge. Further to this, you can choose how to structure your 5+ forum posts and final write-up, however, content should be clear and follow the evolution of your project through to completion.

Media-rich posts will be judged more favorably so, where possible, share your work by including:

Photos
Videos
Code samples

Overall - express your creativity, ingenuity, knowledge, and hard work 🙂 In line with this, a reminder that it is not acceptable to create Design Challenges entries (or Project14 / RoadTest content) using an LLM or OpenAI's ChatGPT or similar. This is covered further in a post over in the Feedback & Support sub-group.

There have already been a very good number of project updates here in the Smart Spaces forum, but for further inspiration you can always take a look at previous Design Challenges like the Start A Movement competition. Click here to go straight to the final project write-ups.

BAD LINK -- Link to Project page in challenge requirements leads to another challenge.

skruglewicz — Fri, 10 Oct 2025 16:32:25 GMT

Hi cstanton and fellow challenges/

the project link on the challenge requirements page leads to another challenge page?

Challengers must post their progress and a final project article,

https://community.element14.com/challenges-projects/design-challenges/shift-it-warehouse-automation-design-challenge/a/projects

this goes to the /"shift-it-warehouse-automation-design-challenge/" which has completed?

I created a draft and posted to this unknowingly

At Adaptive Environmental Monitoring and Smart Access Control

Hopefully cstanton you can move it to this challenge? let me know?

having trouble POSTING a new project -- cannot add a category?

skruglewicz — Fri, 10 Oct 2025 16:14:20 GMT

hi cstanton and fellow challengers

Creating a NEW project in the challenges, I cannot enter in a category? I'm dead in the water here?

what are valid categories? I received an error as follows

I'm dead in the water here?

Forum Post #5: Adaptive Environmental Monitoring and Smart Access Control

skruglewicz — Fri, 10 Oct 2025 05:12:33 GMT

An Outline -Testing & Running the Smart Spaces Project

This project presents an outline, designed to serve as a practical tool for organizing and documenting my work on adaptive environmental monitoring and smart access control using NXP development kits. The structured workflow supports my process in drafting a comprehensive project document for the challenge, ensuring systematic coverage from hardware setup to final deployment.

I want to mention that I actively use LLMs (Large Language Models) for my daily activities in both professional and hobbyist settings. Prompt engineering and working with LLMs is something I’m greatly interested in—I’m constantly crafting prompts to support my job, technical writing, and brainstorming ideas for projects. For me, LLMs are invaluable tools that help spark creativity and refine ideas as I work through project challenges.

For this forum discussion, I did some brainstorming with Perplexity one of my LLM tools that I use quite often. after much prompting about what I was thinking we came up with this outline. The outline lays out suggested steps for testing and bringing the distributed building automation system online using the NXP FRDM MCX A153 (hub) and MCX N236 (edge node) development kits.

1. Hardware Preparation and Safety

Check boards & workspace: Lay out the MCX A and at least one MCX N board on an ESD-safe surface. Inspect for bent pins or loose components.

Review manuals: Double-check quick start guides for both boards. Confirm required sensor modules are present and supported.

2. Initial Power-Up and Verification

Connect boards to PC: Use the included USB cables; MCX A to a Type-C port, MCX N to microUSB.
Power LED check: Make sure each board's green power LED lights up.
IDE detection: Open MCUXpresso IDE. Check 'Debug Probe' list for both boards — confirm CMSIS-DAP/J-Link is recognized.

3. Flash Test Firmware

Select demo apps: In MCUXpresso, locate and build 'Hello World' (UART printout) or 'LED blink' demo for each board (from NXP SDK).
Flash to boards: Follow IDE prompts to program the boards via MCU-Link interface.
Confirm execution: Watch for LED blinking or serial output in MCUXpresso’s terminal window.

4. Sensor Integration and Verification

Attach sensors: Plug temperature, humidity, light, and motion sensors into MCX N board’s sensor headers as described in the manual.
Sensor demo: Flash sample code that prints sensor data to serial terminal. Adjust sensors physically (e.g., shine light, apply heat) and verify real-time values update in MCUXpresso.
Troubleshoot: If sensor values are off, check wiring, supported voltages, and code initialization routines.

5. System Communication Test

Wired test: Connect MCX N node to MCX A hub via UART or SPI, as planned. Flash demo code where sensor data is forwarded from N to A and printed via A’s UART.
Node recognition: Confirm that MCX A parses distinct node IDs and logs received values to terminal or onboard LCD.
Network expansion (optional): Attach additional MCX N boards to simulate multi-zone coverage. Confirm unique data from each node.

6. Adaptive Control Logic

Write simple logic: Program MCX A to trigger an output (e.g., toggle relay or onboard LED) if a sensor value exceeds threshold (e.g., temperature > 28°C).
Run system: Verify outputs activate as environmental conditions change. Adjust sensor inputs and watch system response.
Log and document: Copy terminal logs and take timestamped photos/videos for project documentation.

7. Cloud Connectivity (Advanced)

Attach WiFi module: Connect ESP32 or similar module per board’s documentation.
Flash networking demo: Use NXP or third-party examples to send sensor data to a test cloud endpoint (e.g., MQTT or HTTP).
Remote monitoring: View sent data in cloud dashboard or receive via web/mobile app.

8. Project Documentation & Forum Sharing

Save code samples: Archive MCUXpresso projects and demo code.
Capture photos/videos: Document wiring, boards, and screen outputs.
Prepare rich project posts: Write up test results in forum entries, including hardware, code, and troubleshooting tips. Ensure at least 5 media-rich posts before the challenge’s closing date.

Quick Recap:

Inspect hardware and safely connect.
Confirm board detection and flash demos.
Integrate and test sensors, verify system responses.
Link nodes, develop control logic, and validate outputs.
Add cloud connectivity for full-scale smart building automation.

Forum Post #4: Adaptive Environmental Monitoring and Smart Access Control

skruglewicz — Fri, 10 Oct 2025 05:07:44 GMT

Implementation Outline: Using NXP FRDM MCX A & MCX N Development Kits

This post outlines the design and implementation of an adaptive environmental monitoring and smart access control system using NXP FRDM MCX A153 (central hub) and MCX N236 (edge node) development kits. The idea stemmed from a need for intelligent building automation—one that adapts to environmental changes while managing secure access. The goal was to combine adaptive monitoring and smart access control in a distributed architecture.

It is a brief outline to aid myself in what is possible for eventually implementing my idea in a spart spaces project for the challenge. I tried to cover the project’s motivation, concept-to-design progression, in-depth comparison of both development boards, development environment, possible sensor selection, and implementation outline from unboxing to integration. I will be using these forum post to construct my final Project. Hope you find this interesting and will review my project when it is submitted.

Basic Design

Central Hub: Select the NXP FRDM MCX A153 board for its processing power and connectivity, serving as the main coordinator.
Edge Nodes: Deploy NXP FRDM MCX N236 boards in various building zones to interface with environmental sensors.
System Layout: Design the network such that edge nodes monitor local conditions and relay data to the central hub, which aggregates and acts on this information.
Connectivity: UART will be used to connect the two devices.
Sensors & Control: Choose sensors for temperature, humidity, motion, and air quality; include relays for lighting and HVAC.

Comparison: NXP FRDM MCX A153 vs. NXP FRDM MCX N236 Development Kits

Similarities

Feature	FRDM MCX A153	FRDM MCX N236
MCU Architecture	Arm Cortex-M33	Arm Cortex-M33
Debug Capability	MCU-Link onboard debugger	MCU-Link onboard debugger
Expansion Connectors	Arduino UNO R3 headers, mikroBUS	Arduino UNO R3 headers, mikroBUS
User Interaction	Push buttons, RGB/power LEDs	Push buttons, RGB/power LEDs
Communication Protocols	I2C, SPI, UART	I2C, SPI, UART, CAN
Development Environment	MCUXpresso IDE	MCUXpresso IDE
Power Supply	USB (Type-C or microUSB)	USB (Type-C or microUSB)

Both kits are designed for rapid prototyping, use the same IDE/software tools, support rich peripheral expansion, and offer plug-and-play sensor integration.

Differences

Feature	FRDM MCX A153	FRDM MCX N236
Physical Size	More compact	Larger, with more densely packed features
MCU Model	MCX A153VLH	MCXN236VDFT (TrustZone security enabled)
Onboard Sensors	None built-in	3-axis accelerometer, visible light sensor, digital microphone
Flash Memory	Internal only	+ 64Mbit QSPI flash onboard
CAN Bus Support	No	Yes, with onboard CAN transceiver (TJA1057)
Multimedia Hardware	No direct support	LCD (FlexIO), camera interface
Developed Use Cases	Low-power industrial, secure IoT hub	Sensor-rich IoT and AI edge applications
Connectivity Types	Standard USB Type-C	Micro USB Type-A to Type-C

Sensors

FRDM MCX A153:
No built-in sensors; relies on expansion via Arduino sockets, mikroBUS, or Pmod for external sensors (environmental, motion, etc.).
FRDM MCX N236:
Built-in 3-axis FXLS8974CFR3 accelerometer, visible light sensor, digital microphone, and supports sensor add-ons via headers.

Pins & Expansion

Both boards offer:

4x Arduino UNO R3-compatible sockets/headers for shields
2x mikroBUS sockets/headers for click modules
1x Pmod header for Digilent Pmod peripherals
MCX N236 adds:
- FlexIO header for LCD
- Camera header for image applications
- Dedicated CAN header

Development Environment

MCUXpresso IDE is used by both boards for firmware development, debugging, and demo application deployment.
Both boards are detected via MCU-Link CMSIS-DAP interface.
SDK examples and board support files are available for each.

Step-by-Step Implementation Guide

Unbox the Kits

Unpack both MCX A153 (hub) and MCX N236 (edge node) boards.
Check for all necessary cables (USB Type-C, Micro USB), Quick Start Guides, and accessories.

Inspect the Boards

Carefully look for any bent pins or loose components.
Identify expansion headers for sensors: Arduino R3, mikroBUS, Pmod on MCX A, sensor connectors on MCX N.

Connect to Power

Plug the provided cables from MCU-Link ports to your PC.
Ensure the green power LEDs illuminate on both boards.
Confirm your PC recognizes the debug interfaces (CMSIS-DAP/J-Link).

Install Development Software

Download MCUXpresso IDE from NXP.
Install board support packages and required drivers for both boards.

Verify Board Communication

Open MCUXpresso IDE; verify both boards are detected under debug probes.
Flash a basic “Hello World” or LED blink demo to confirm setup and firmware flashing.

Connect and Test Sensors

Attach basic sensors (temperature, humidity, light, motion) to MCX N boards per the manual.
Use NXP’s demo applications to read sensor outputs within the IDE.

Plan Network Architecture

Deploy MCX A as the central hub, aggregating sensor data from MCX N nodes.
Define connections—UART, SPI, I2C, CAN—for data movement between hub and edge nodes.
Integrate cloud connectivity for remote monitoring/control.

Begin Full Integration

Start coding your building automation logic; MCX A manages central control and cloud comms.
Edge MCX N boards handle local sensor data and respond to events.
Continually document the process: take hardware photos, save code samples, and post regular updates to the challenge forum.

Tips:

Seek troubleshooting help via NXP’s Quick Start Guides and community forums.
Favor media-rich posts—photos, videos, and technical documentation—for higher challenge scores.

Forum Post #3: Adaptive Environmental Monitoring and Smart Access Control

skruglewicz — Fri, 03 Oct 2025 02:49:40 GMT

Forum Post #3:
Adaptive Environmental Monitoring and Smart Access Control

Step-by-Step Guide to NXP FRDM MCX A & MCX N Development Kits

This document is a **step-by-step guide** for unboxing and setting up the NXP FRDM MCX A and MCX N development kits, specifically for a building automation project. It walks you through the entire process—from hardware inspection and power-up to installing development software, verifying board communication, connecting sensors, planning network architecture, and documenting each step for effective forum sharing. The series provides clear instructions to help users go from unboxing the hardware to integrating all components in a scalable smart automation solution.

Step-by-Step Guide

1. Unbox the Kits

Remove both the NXP FRDM MCX A153 (central hub) and NXP FRDM MCX N236 (edge node) boards from their boxes.
Check the packaging for cables (USB Type-C for MCX A, Micro USB for MCX N), Quick Start Guides, and any additional accessories.

2. Inspect the Boards

Carefully examine both boards for bent pins, loose components, or surface damage.
Note each board's expansion headers: Arduino R3 sockets, mikroBUS, Pmod (on MCX A), sensor connectors, USB ports.

3. Connect to Power

Attach the provided USB cable from the "MCU-Link" debug port to your computer for each board.
Verify the power indicators:
- MCX A: Green LED should light up.
- MCX N: Green LED should also indicate successful power.
Your computer should auto-detect a CMSIS-DAP or J-Link debug interface (may prompt for drivers).

4. Install Development Software

Download and install MCUXpresso IDE from NXP’s official website (as described in the Quick Start Guide).
Follow the instructions to install board support and necessary drivers for both MCX A and MCX N.

5. Verify Board Communication

Open MCUXpresso IDE and verify that both boards appear under connected debug probes.
Try flashing a prebuilt "Hello World" application or blinking LED demo to confirm setup.

6. Connect and Test Sensors

For MCX N boards: connect basic sensors (temperature, humidity, light, motion) to headers as specified in the board manual.
Use provided demo applications to read sensor values in MCUXpresso IDE.

7. Network Architecture

Deploy MCX A as the central hub, aggregating sensor data from multiple MCX N nodes deployed in building zones.
Plan connections and communication protocols: use UART, SPI, I2C, or CAN as supported.

8. Begin Project Integration

Start building your distributed building automation solution, following challenge requirements:
- MCX A manages control logic and cloud communication.
- MCX N boards act as sensor-rich edge nodes.
- Document progress with photos, code snippets, and stories for forum updates.

Tip: Reading official Quick Start Guides and checking the NXP community forums for board-specific troubleshooting will speed up setup..

Smart Spaces - NXP eIQ toolkit in AI model and training

fyaocn — Thu, 25 Sep 2025 08:50:48 GMT

1 Install eIQ

Download and install eIQ from NXP website

The plugins and install packages are extracted, installed and configured.

Until the installation complete.

2 Start eIQ

Start eIQ and enter welcome page for different components,

Remote device like USB camera can be added for image capture for dataset

This is Time series studio for time-series dataset, training with many model available to use.

The create new project can create new project use images,

now, only three model is supported

After model is selected, the UI appears for dataset import and model training

3 Use time series studio

Create new project

select hardware, now FRDM-MCXN236 and not support for FRDM-MCXA153

then select raw data which is in csv format or txt format, there are three channel created,

start training, with memory allocation shown.

the train in progress,

with training process in active windows

after the training completed, deploy the result , generate files to embedded in the project or direct generate one project.

This is how the eIQ shall be used in designing and the toolkit is well and easy to be used.

Smart Spaces - Import New Project with NXP Application Code Hub

fyaocn — Wed, 24 Sep 2025 07:08:28 GMT

1 Import New Project with NXP Application Code Hub

Start with the "Motor RPM Grapher in OLED with USB" project from NXP Application Code Hub.

Start from import project

Search and select the demo project fit well.

Now press next,

Then press github link to next step

clone the repository into local

Press fininsh to complete.

2 Build and download

Its core function is to realize real-time motor speed (RPM) acquisition and visualization using the FRDM-MCXA153 development board: The board connects to the main control panel via USB to receive motor speed data, and displays the speed information in real time in a graphical format through the Mikroe OledBClick OLED display module.

Key project tags are summarized in the table below:

Category	Details
Core Development Board	FRDM-MCXA153
Application Categories	HMI (Human-Machine Interface), Industrial, Graphics
Peripherals Used	GPIO (General-Purpose Input/Output), I2C (Inter-Integrated Circuit), USB
Supported Toolchains	MCUXpresso IDE, VS Code

Press build to start build

The build process is passed with no error.

Press debug,

During first debug, Port Probe to SWO port

Then CMSIS-DAP is probed

Now, the debug can be stopped since the code is flashed into the MCU

3 Summary

Even import example from SDK is normally more accessible, Application code hub can bring more complex demo project as template for further development.

Smart Spaces - Getting start with FRDM-A153 from MCUxpresso IDE and Power Up

fyaocn — Tue, 23 Sep 2025 02:06:48 GMT

1. Summary

MCUxpresso IDE shall be normally used for FRDM-MCXA153 development board.

Software development environment setup, and example project execution start with validating hardware functionality by connecting a Type-C USB cable to the J15 interface; then importing the SDK_2.x_FRDM-MCXA153， configuring UART (with parameters like 115200 baud rate) to get started with this Arm Cortex-M33 coreboard. Here is how getting start up shall go.

2. Detailed

I. Hardware Basics & Initial Validation

Core Board FeaturesBased on the Arm Cortex-M33 microcontroller, the board operates at a maximum frequency of 96 MHz, with high-speed connectivity, serial peripherals, timers, analog functions, and low-power characteristics. It comes pre-loaded with an LED blinky demo for out-of-the-box functionality verification.
Hardware Connection & Testing
- Connection Method: Use a Type-C USB cable to connect the board’s J15 interface (MCU-Link USB) to a computer or power supply.
- Verification Phenomenon: Upon successful power-up, the RGB LED should blink at a steady rhythm, that is about 1 second interval.

II. Software Development Environment Setup

Install Mcuxpresso IDE and SDKs

After start up, the new version change with new UI

Then goes to deshboard page

Other type of IDE is available as well

Tool Type	Recommended Version/Configuration	Core Purpose	Key Settings
Primary IDE	MCUXpresso IDE 11.8.0+	End-to-end project creation, compilation, debugging	Supports SDK import and CMSIS-DAP probe connection
Cross-Platform IDE	VS Code + MCUXpresso Extension	Development on Windows/macOS/Linux	Requires importing local SDK archive (e.g., SDK_2_14_0_FRDM-MCXA153.zip)
Other IDEs	IAR Embedded Workbench 9.40.1+	Development for Cortex-M33 core	Set debugger to CMSIS-DAP; target device = NXP MCXN947_core0
Other IDEs	Keil µVision 5.33+	Requires CMSIS device pack (MCXNXXX_DFP)	Select J-LINK in debug options

III. SDK Import & Project Workflow

SDK Acquisition & Import
- SDK Version: Recommended SDK_2.x_FRDM-MCXA153 which must be unzipped in advance.
- Import Path: In the IDE’s "Quickstart Panel", click Import SDK example(s) and select the FRDM-MCXA153 board and corresponding SDK.

Drap and install the sdk automatically

Plug in the board, the CMSIS-DAP driver is installed automatically and virtual port is added.

3. MCUXpresso IDE Project Operations

Step	Details
Project Selection	Expand `demo_apps` to select `hello_world`, or expand `driver_examples` to select `ctimer_match_interrupt_example`
Configuration	Check UART as the SDK Debug Console (replacing default semihosting)
Project Build	Click the "Build" button; success is indicated by 0 errors and 0 warnings in the console (takes ~15 seconds)
Program Download	Click the "Debug" button, select the MCU-Link CMSIS-DAP probe, and the program will be automatically downloaded to the board
Result Verification	Open the terminal (configured as per the table above) and view output like "Hello World" after running the program

The power up of FRDM-MCXN236 is similar with with blink as out-of-factory demo.

It is well and ready to code .

Forum - Recent Threads

Smart Spaces Design Challenge - Winners Announcement

Finished publishing my project

DDS Elevator - Measuring up

Table of Contents

Introduction

TOF sensor

Interfacing multiple TOF sensor

Using ESP32 for interfacing with i2c

Failed Communication attempts

SPI interface

CAN interfacing

Conclusion

Writing up my project report

Smart Spaces - Using RT-Thread with FRDM- MCXA153

1 Brief on RT-Thread

2 Develop with SCons and Virtual ENV

3 Build the project with scons

4 Flash the board

5 Run with the blinky

DDS Elevator - Enabling LPUART in N236 board for Serial communication

Table of Contents

Introduction

Pin Configuration

Clock

Peripheral

Transfer Method

Callback

Modifying Driver code

Configuring Read Non-blocking function

Output

Conclusion

Configuring LPUART on MCXN236 - A frustrating experience

DDS Elevator - Bit of human touch

Table of Contents

Why HMI

Struggling with setting up multiple UART

Scalability issue

Initial idea

Daisy chaining

Programming the HMIs

UI – Dynamic Floor selection

UI – Getting user input

UI – Feedback response from microcontroller

Conclusion

References

Switched from MCXA153 to MCXN236

NO connection to chips debug port on the MCXN236?

Configuring LPTMR0 on MCXA153

Smart Spaces - NXP eIQ Time Series Studio on MCXN236 and There is a fault

1 Create Motor fan state project in NXP-Eiq

Fan States:

2 Training

3 Emulating

4 Generate code

5 Generate code and download

Detecting devices on the I2C bus

DDS Elevator - Hello World!!!

Table of Contents

First Impressions

FRDM A153 board

FRDM N236 board

Software and SDK

MCUXpresso

Creating a new project

Note on Arduino support

Test Projects

LED Blink

Hello World

Timing and Delay

Thumbs up for

Thumbs down for

Quick links

Conclusion

PROBLEMS - Using MCUXpresso IDE with MCXA153 and MCXN236 on the same PC

Smart Spaces Design Challenge - Deadline Extended by Two Weeks!

Smart Spaces Design Challenge - Some Quick Guidance on Project Updates & Final Write-Ups

BAD LINK -- Link to Project page in challenge requirements leads to another challenge.

having trouble POSTING a new project -- cannot add a category?

Forum Post #5: Adaptive Environmental Monitoring and Smart Access Control