Forum - Recent Threads

RE: NO connection to chips debug port on the MCXN236?

skruglewicz — Thu, 18 Dec 2025 03:30:16 GMT

UPDATE STATUS on the problem

Success

What was the reason?

Turns out there were multiple versions of the MCU-Link firmware on my troubled PC. And as I found two Common Causes of Persistent Debugging Connection Failures may be the reason for persistent debugging problems:

Corrupted or Conflicting USB/Debug Drivers: Drivers (MCU-Link / CMSIS-DAP / WinUSB) on the original PC may be corrupted or conflicting. This can result from prior installations of probes from NXP, SEGGER, PE Micro, or others.
Stale LinkServer Instance or Configuration: The IDE may be repeatedly reusing a stale or mismatched LinkServer instance or configuration on the original PC. This allows the probe to enumerate, but the SWD connection to the target core never actually establishes.

What I did to get it working without getting the Error.

I went into add/remove programs and noticed there were 3 versions of the MCU-Link Firmware install on my PC
Here is the program screen showing 3 versions!

I uninstalled all but
Mcu-Llnk firmware V3.148
MCUXpresso ID V25.6
I didn't need the other tools.

Now debug does not get the error as I described and works all the time?
SUCCESS !!! I'm back on track with debugging on the MCXN236

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

RE: NO connection to chips debug port on the MCXN236?

skruglewicz — Thu, 18 Dec 2025 03:27:11 GMT

UPDATE STATUS on this problem

It works on the new PC with a clean MCUXpresso + SDK install, so the board and probe are fine, and the root cause is almost certainly something broken or conflicting on the original PC’s toolchain/driver side rather than the hardware.

Brief summary

On a new PC I installed MCUXpresso (24.12) and the SDK (24.12.00), connected the FRDM‑MCXN236, built an example, and debug worked immediately. On the original PC I have MCUXpresso 25.6 with SDK 25.09.00, and despite reinstalling, updating LinkServer, trying LinkFlash, firmware updates, and ISP/bootloader mode, you still get Ee(42). Could not connect to core / No connection to chip's debug port.That confirms the FRDM‑MCXN236 and MCU‑Link firmware are good and isolates the problem to the original Windows environment.

Likely causes on the original PC

Most probable categories, given that the exact same board works elsewhere:

Corrupted or conflicting USB/debug drivers (MCU‑Link / CMSIS‑DAP / WinUSB) on the original PC, possibly from prior NXP, SEGGER, PE Micro, or other probe installs.
A stale or mismatched LinkServer instance or config on the original PC that the IDE keeps reusing, so the probe enumerates but SWD never actually connects to the target core.
Security/IT software (AV, endpoint protection, USB control) on the original PC interfering with USB enumeration or blocking the debug interface, while the new laptop is more “clean.
Leftover MCUXpresso or SDK fragments from original versions in different paths, causing the IDE to point at the wrong debug driver or XML/config for MCXN236 even though the latest SDK is installed.

I have researched a few things I could try which I will and update this post. so stay tuned

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

skruglewicz — Thu, 18 Dec 2025 02:13:01 GMT

The problem manifested itself before I installed the IDE v24? that I installed in the hopes to fix my problem

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

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

Jan Cumps — Tue, 16 Dec 2025 14:01:22 GMT

The strange thing is that you have an older version of both the IDE and debug software installed after a newer version.

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

skruglewicz — Tue, 16 Dec 2025 07:50:44 GMT

wrong comment see: NO connection to chips debug port on the MCXN236?

RE: Smart Spaces Design Challenge - Winners Announcement

robogary — Sun, 07 Dec 2025 14:35:15 GMT

Fantastic project ideas

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

[mention:6554aa80b5274fc6a0375c92988b98fa:e9ed411860ed4f2ba0265705b8793d05] 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

[mention:0efb99a0781d451ca8d92994f291749f:e9ed411860ed4f2ba0265705b8793d05] 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

[mention:b44f14232ddb4410a1e3f218f750af5c:e9ed411860ed4f2ba0265705b8793d05] 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.

[mention:2c8bbc1da27c407d8ce40210ca76ae9a:e9ed411860ed4f2ba0265705b8793d05] will be in touch to arrange the shipment of the prizes [emoticon:8416d71642834782a5fe858404490f18]

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

RE: Smart Spaces Design Challenge - Winners Announcement

skruglewicz — Sat, 06 Dec 2025 01:46:40 GMT

First of all, A huge thanks to JoRatcliffe and cstanton for putting together such a successful and enjoyable challenge. The road was a bit rocky at first, but in spite of the bumps you both pulled it off and created a really engaging experience for everyone.

At first there was some hesitation and confusion about the new format of 5+ forum posts plus a project instead of the older 5–10 blog approach, but in practice it has turned out to make a lot of sense for this kind of challenge. The structure encouraged more frequent interaction, troubleshooting, and sharing along the way, which really added to the community feel.

Work will definitely continue on the project implementation, and another MCXN236 is needed now that the current one has effectively become a brick. If there happens to be a spare MCXN236 lying around, @cstanton , feel free to send it this way—it would be great to fully realize the edge node now that there is a much better understanding of the platform.

A big thank you to everyone behind the scenes – the judges, reviewers, community managers, and all the folks at element14 and NXP who made this challenge possible and kept everything running smoothly.

Special appreciation goes out to anyone who takes the time to review my Adaptive Environmental Monitoring and Smart Access Control project. Your feedback and insights are incredibly valuable as work continues on the implementation and refinement of this system.

Looking forward to hearing your thoughts, suggestions, and any technical feedback as this project evolves from prototype to a more complete solution. The collaborative spirit of this community has been amazing, and it's exciting to keep building on what was started here.

Thank you all again for this opportunity and recognition!

RE: Smart Spaces Design Challenge - Winners Announcement

skruglewicz — Sat, 06 Dec 2025 01:04:32 GMT

Warm congratulations, @yamanoorsai – fantastic work on your project and the finisher recognition.

Your TinyML exhaust fan concept is very inspiring, and the way you approached low-power smart ventilation is going to be a big help as work continues on implementing my design. The clear documentation and practical focus make it a great reference, and it is exciting to keep learning from what you have built.

Thanks

Steve K

RE: Smart Spaces Design Challenge - Winners Announcement

skruglewicz — Sat, 06 Dec 2025 00:56:49 GMT

Thank you so much, @kmikemoo – that means a lot

The spirit of cooperation and open sharing you mentioned was exactly what made this challenge such a great experience, and your encouragement and participation were a big part of that atmosphere. It was a pleasure building and learning alongside everyone, and comments like yours really highlight what makes the element14 community special.

thanks Steve K

RE: Smart Spaces Design Challenge - Winners Announcement

skruglewicz — Sat, 06 Dec 2025 00:51:25 GMT

Thanks dougw , I'm excited to get the loot.

RE: Smart Spaces Design Challenge - Winners Announcement

skruglewicz — Sat, 06 Dec 2025 00:49:31 GMT

GOOD JOB balajivan1995

Huge congratulations, on a truly well-deserved result in the Smart Spaces Design Challenge.

Your project and writeups were impressive, but what stood out just as much was your willingness to collaborate and support others throughout the competition. Your forum posts were a big help in understanding the IDE and getting the most out of the NXP FRDM MCX boards, and you always came back with thoughtful answers to questions.

Thank you for being such a generous and engaged member of the community, and for helping make this challenge more enjoyable and accessible for fellow participants. Well done, and hope there are many more projects and wins ahead for you.

looking forward to share more of my trials and tribulations with the IDE and NXP FRDM MCX eval board.. I might have to breakdown on order another MCXN236 board, as you know mine is not able to flash or debug. I plan to keep working on my project and get it implemented.

You Rock!

skruglewicz

RE: Smart Spaces Design Challenge - Winners Announcement

yamanoorsai — Fri, 05 Dec 2025 22:54:27 GMT

Thanks. Congratulations to skruglewicz balajivan1995 This contest was absolute fun.

RE: Smart Spaces Design Challenge - Winners Announcement

kmikemoo — Fri, 05 Dec 2025 17:18:02 GMT

Congratulations to skruglewicz , balajivan1995 and yamanoorsai . I think what I admired most about this design challenge was the cooperation and open sharing of information. Well done!

RE: Smart Spaces Design Challenge - Winners Announcement

dougw — Fri, 05 Dec 2025 15:43:29 GMT

Congratulations to the winners. Have fun with the loot.

RE: Smart Spaces Design Challenge - Challengers Announcement

balajivan1995 — Fri, 05 Dec 2025 12:21:23 GMT

Thank you, guys!

Especially for following up with the board and getting it properly delivered and for the timely announcement as well!

This was indeed a really challenging one, wish I could have completed more of what I intended. Congratulations to skruglewicz and yamanoorsai .

RE: Smart Spaces - Using RT-Thread with FRDM- MCXA153

embeddedguy — Wed, 03 Dec 2025 16:44:51 GMT

Congratulations on your first steps with RT-Thread RTOS.

I know this RTOS but have not yet given it a try.

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

[embed:dc8ab71f-3b98-42d9-b0f6-e21e02a0f8e2:f300bfd3-16a7-426b-b1ea-c6b249b94794:type=c_cpp&text=%23include%20%3Crtdevice.h%3E%0D%0A%23include%20%22drv_pin.h%22%0D%0A%0D%0A%23define%20LED_PIN%20%20%20%20%20%20%20%20%28%283%2A32%29%2B12%29%0D%0A%0D%0Aint%20main%28void%29%0D%0A%7B%0D%0A%23if%20defined%28__CC_ARM%29%0D%0A%20%20%20%20rt_kprintf%28%22using%20armcc%2C%20version%3A%20%25d%5Cn%22%2C%20__ARMCC_VERSION%29%3B%0D%0A%23elif%20defined%28__clang__%29%0D%0A%20%20%20%20rt_kprintf%28%22using%20armclang%2C%20version%3A%20%25d%5Cn%22%2C%20__ARMCC_VERSION%29%3B%0D%0A%23elif%20defined%28__ICCARM__%29%0D%0A%20%20%20%20rt_kprintf%28%22using%20iccarm%2C%20version%3A%20%25d%5Cn%22%2C%20__VER__%29%3B%0D%0A%23elif%20defined%28__GNUC__%29%0D%0A%20%20%20%20rt_kprintf%28%22using%20gcc%2C%20version%3A%20%25d.%25d%5Cn%22%2C%20__GNUC__%2C%20__GNUC_MINOR__%29%3B%0D%0A%23endif%0D%0A%0D%0A%20%20%20%20rt_pin_mode%28LED_PIN%2C%20PIN_MODE_OUTPUT%29%3B%20%20%2F%2A%20Set%20GPIO%20as%20Output%20%2A%2F%0D%0A%20%20%20%20rt_kprintf%28%22MCXA153%20HelloWorld%5Cn%22%29%3B%0D%0A%0D%0A%20%20%20%20while%20%281%29%0D%0A%20%20%20%20%7B%0D%0A%20%20%20%20%20%20%20%20rt_pin_write%28LED_PIN%2C%20PIN_HIGH%29%3B%20%20%20%20%2F%2A%20Set%20GPIO%20output%201%20%2A%2F%0D%0A%20%20%20%20%20%20%20%20rt_thread_mdelay%281000%29%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2A%20Delay%20500mS%20%2A%2F%0D%0A%20%20%20%20%20%20%20%20rt_pin_write%28LED_PIN%2C%20PIN_LOW%29%3B%20%20%20%20%20%2F%2A%20Set%20GPIO%20output%200%20%2A%2F%0D%0A%20%20%20%20%20%20%20%20rt_thread_mdelay%28500%29%3B%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2F%2A%20Delay%20500mS%20%2A%2F%0D%0A%20%20%20%20%20%20%20%20rt_kprintf%28%22MCXA153.%5Cn%22%29%3B%0D%0A%20%20%20%20%7D%0D%0A%7D%0D%0A]

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 - 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.

[View:/cfs-file/__key/communityserver-discussions-components-files/441/tof_5F00_reading.webm:640:360]

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.

RE: DDS Elevator - Measuring up

balajivan1995 — Wed, 03 Dec 2025 14:27:52 GMT

The original plan was to place the entire PCB board on top of an elevator model. Three elevators placed side by side, travelling up and down. Each tof sensor will be placed on top of each of the elevators so that ESP32 can calculate the distance the cabin is currently in.

If the lift is in topmost floor, the sensor reading will be around 15-25cm, the next immediate floor will be at 165-180cm and so on. (In terms of practical values)

Let's say, if the person in the topmost floor wants to move to the next floor, the main controller will start the motor in reverse direction so that the cabin will be lowered. If the cabin reaches the distance of 165-180cm, it will assume the cabin has reached the destination and it will start engaging the landing procedure.

Image taken online for reference and added text overlay.

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.

RE: DDS Elevator - Measuring up

colporteur — Tue, 02 Dec 2025 16:13:08 GMT

What are your plans for I2C from the sensor to the ESP32. I assume they will be some distance apart. I2C doesn't travel well if I recall Clems video How Far Can I2C Go? -- Episode 666

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.

Forum - Recent Threads

RE: NO connection to chips debug port on the MCXN236?

What was the reason?

What I did to get it working without getting the Error.

NO connection to chips debug port on the MCXN236?

RE: NO connection to chips debug port on the MCXN236?

UPDATE STATUS on this problem

Brief summary

Likely causes on the original PC

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

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

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

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

RE: Smart Spaces Design Challenge - Winners Announcement

Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Winners Announcement

RE: Smart Spaces Design Challenge - Challengers Announcement

RE: Smart Spaces - Using RT-Thread with FRDM- MCXA153

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 - 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

RE: DDS Elevator - Measuring up

Finished publishing my project

RE: DDS Elevator - Measuring up

Writing up my project report