Porting an ST Application
This section outlines the process of migrating an application developed in the STM32Cube IDE to the NXP MCUXpresso VSCode extension, using a compatible SDK for the target NXP MCU.
For users familiar with STM32Cube IDE, maintaining a similar development environment can ease the transition and reduce the learning curve. In this example, an I2C-based application originally developed for an STM32 device will be recreated and adapted for an NXP MCU.
The migration begins by creating a minimal project in MCUXpresso that includes the necessary I2C drivers. The original ST application utilizes two I2C instances for communication between components on the same board. To replicate this functionality, two sets of I2C pins must be initialized. Additionally, the application uses a push-button input and an LED output to demonstrate behavior changes, requiring the configuration of corresponding GPIOs using the MCUXpresso pin configuration tools.
MCUXpresso for Visual Studio Code
MCUXpresso Installer
In addition to the MCUXpresso extension, some extra tools and software are required for the full development flow within VS Code. All these dependencies are managed by the MCUXpresso Installer from QUICKSTART PANEL view.
This launches the Installer UI, where an intuitive interface allows users to select from Software Kits, Debug Probes, Standalone Tools, or ARM components.
Using the MCUXpresso Installer, select MCUXpresso SDK Developer, LinkServer, SEGGGER J-Link, PEmicro, and MCUXpresso Configuration Tools then Click Install.
Once all dependencies have finished installing, you can safely close the MCUXpresso Installer.
Import Repository
The first step in the MCUXpresso for VS Code development flow is to import an SDK software repository.
Go to the MCUXpresso for VS Code extension
Click Import Repository in the QUICKSTART PANEL
Select MCUXpresso SDK, main revision, choose your SDK destination folder. When finished, click Import
NOTE this import step takes a long time to clone. VS Code shows a progress bar pop-up with the status of the west tool as it clones all the repos.
The repository should be added to the IMPORTED REPOSITORY view one the import is successful
Importing Example from Repository
In the QUICKSTART PANEL click Import Example from Repository.
Choose the following board settings to import a Freestanding application
To select the board, type MCXA15 to find FRDM-MCXA156
Type hello to find the demo_apps/hello_world
For application type, select Freestanding application
Change the Name to frdmmcxa156_i2c
Click Import and the example should be added to the PROJECTS view
In the PROJECTS window open Project Files --> prj.conf and add CONFIG_MCUX_COMPONENT_driver.lpi2c=y to add I2C driver support to your project.
To begin the migration, the main source file from the original ST project—as well as any custom source files not part of the standard ST driver set—should be incorporated into the new NXP project.
The following steps outline the initial project setup in MCUXpresso for VS Code:
Upon creation, the project includes a basic "hello_world" example. This template can be used as a starting point. All content within the main source file—except for the initial macro definitions—can be replaced incrementally to integrate the application logic, allowing for a modular and controlled migration process.
Functions quick summary from ST project
The next step involves transferring the main source file from the original ST project into the newly created MCUXpresso project. During this process, standard ST includes, and driver references are excluded, unless custom header files are required. In this case, no custom headers are used, so only the core application logic is migrated.
Many of the function calls within the ST source file rely on STM32-specific HAL APIs. These will be reviewed and systematically replaced with equivalent functions from the NXP SDK. The approach involves analyzing each function within the main() routine to understand its purpose and then substituting it with the corresponding implementation in the NXP environment.
Interrupt Priority Configuration Configures the microcontroller’s interrupt system to manage priority levels when multiple interrupts occur simultaneously.
Power Peripheral Clock Enablement Activates the clock for the Power (PWR) peripheral, a prerequisite for configuring power management settings.
Power Management Setup Initializes power management features of the STM32U5xx microcontroller to optimize energy efficiency and performance across internal components.
System Clock Configuration Sets up the timing system of the microcontroller, configuring it to operate at a frequency of 160 MHz.
Peripheral Initialization Establishes pin configurations and functional settings for peripherals. In this application, I2C1 is configured as the follower and I2C3 as the leader.
LED Initialization Configures the LED to start in a low-active state, turning it on to indicate initial status or communication feedback.
GPIO Polling for Button Press Continuously monitors the status of a GPIO input pin. If the button is not pressed, the LED blinks rapidly. Once pressed, the loop exits, and the LED remains on.
I2C Communication Start Initiates the I2C communication process from the master side, triggering data transfer between the two I2C interfaces.
How is this handled in the NXP SDK?
1. Interrupt Priority Configuration This functionality is supported through CMSIS core NVIC functions and can be reused directly. It requires defining macros to establish the desired pre-emption priority levels.
2–4. Clock and Power Configuration
These aspects are consolidated within the BOARD_InitBootClocks function, located in clock_config.c under the board folder. This function initializes both the system clock and power settings for the NXP MCU.
5. Peripheral and Pin Initialization Peripheral setup is divided across two functions:
BOARD_InitBootPins (in pin_mux.c) handles pin configuration for I2C and GPIO.
BOARD_InitBootPeripherals (in peripherals.c) manages I2C peripheral initialization and GPIO interrupt setup.
6. LED Initialization GPIO pins can be configured as output high or low depending on the desired initial state. The LED can be toggled or set using GPIO_PinWrite.
7. GPIO Polling for Button Press This behavior can be replicated using a custom polling function that utilizes GPIO_PinRead to monitor the button state.
8. I2C Communication Start The I2C master communication is initiated using LPI2C_MasterStart, which begins the data transfer process with the designated slave device.
Generate Initialization Code with MCUXpresso Config Tools
Clocks
VS Code extension works with Config Tools standalone. To access and use MCUXpresso Config Tools from the MCUXpresso extension in VS Code. In the PROJECTS view, right click on the project folder then select Open with MCUXpresso Config Tools
Config Tools will be open in a new window, because this is the first time the project is being open a config tools overview window will appear. Make sure the project has Pins, Clocks and Peripherals enabled; then click Close.
To configure the system clocks, open the Clocks tool through the menu Tools --> Clocks.
The clock diagram displays the supported configurations for the selected MCU. In this example, the device has a maximum core clock frequency of 96 MHz. As this meets the application's requirements, no modifications to the default clock settings are necessary.
To enable the peripheral clocks for the I2C instances, navigate to the clock configuration diagram within the MCUXpresso Config Tools. Scroll through the diagram to locate the available peripherals and activate the I2C modules by selecting the appropriate clock sources.
To configure the clock source for the I2C0 and I2C3 peripherals, double-click on the CLKSEL field associated with each instance in the clock configuration diagram. For this setup, select FRO_HF_DIV as the clock source for both I2C0 and I2C3.
Next, configure the clock divider by selecting the corresponding CLKDIV field in the clock configuration diagram. The details will appear in the top-right panel of the interface. To enable the clock path to the I2C peripheral, ensure the option divider /2 and Divider clock is running are selected.
At this stage, the I2C peripheral clocks have been successfully enabled.
Pins
In the standalone MCUXpresso Config Tools go to Tools menu and choose Pins.
Using the filter functionality, search for available pins compatible with I2C instance 0. After reviewing the board schematic, pins P0_16 and P0_17 were selected, as they are accessible via a header. Assign the appropriate I2C functionality to these pins by selecting LPI2C0:SDA and LPI2C0:SCL from the configuration options.
Repeat the configuration process for I2C instance 3. Based on the board schematic, pins P3_27 and P3_28 are selected for this instance. Assign the appropriate functionality by selecting LPI2C3:SDA and LPI2C3:SCL within the pin configuration tool.
Once the pin selections are made, a configuration table is generated displaying the routing and settings for each pin. Within this table, use the routing details to configure the pins as required. For the I2C pins, enable internal pull-up resistors to ensure proper signal integrity during communication.
In addition to configuring the I2C pins, it is necessary to set up two GPIO pins—one for input and one for output. On this board, SW2 (P1_7) is designated for button input functionality, while P3_0 is assigned for LED output.
Within the routing details of the pin configuration table, define the behavior for both input and output GPIOs. Based on the application requirements, the output pin should be initialized to a logical low state (select Logical 0) to activate the LED. For the input pin, enable interrupt detection on a falling edge to register button presses accurately.
Peripherals
In the standalone MCUXpresso Config Tools go to Tools menu and choose Peripherals.
Select “Peripheral Drivers” to access the list of supported drivers available for the target device
GPIO1 Configuration
To filter the available peripheral options, enter “GPIO” in the search field within the Peripheral Drivers view. Once the relevant options are displayed, click “OK” to proceed with the GPIO configuration.
To enable the interrupt functionality for P1_7, which is assigned to the button input, begin by selecting a new peripheral driver. Use the filter to search for GPIO, then choose the appropriate driver to activate the GPIO1 interrupt handler.
SYSTICK
Select “Peripheral Drivers” to access the list of supported drivers available for the target device.
To filter the available peripheral options, enter “SYSTICK” in the search field within the Peripheral Drivers view. Once the relevant options are displayed, click “OK” to proceed with the 1ms periodic timer configuration.
Change the Clock source frequence to 24MHz and the interrupt period to 1ms
I2C Master and Slave
Inside the peripheral configuration panel, look for Functional Group then click on Functional Group Properties
In the Functional group properties window, look for Functional groups or Instances. Click Add a new functional group.
Change the new peripheral function group name to BOARD_InitLPI2Cs then click OK
Double check that BOARD_InitLPI2Cs function group is selected
I2C3 Leader/Master
To configure the I2C peripheral, filter the available options by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one for your application and click “OK” to proceed.
Configure I2C3 as the master (leader) device and enable interrupt-driven data transfer. This setup allows the I2C3 instance to initiate communication and handle data transmission using interrupt mechanisms for improved responsiveness and efficiency.
Additionally, enable the interrupt handler for the I2C3 peripheral. Configure the appropriate priority level and activate the Transmit Data Ready flag to support interrupt-driven data transmission.
I2C0 Follower/Slave Configuration
To configure the I2C0 follower peripheral, filter the available drivers by entering “I2C” in the search field within the Peripheral Drivers view. Once the relevant driver is displayed, select the appropriate one and click “OK” to proceed with the configuration.
Configure I2C0 as the slave (follower) device. Enable the interrupt-driven transfer method and specify the slave address to be used for communication. This setup allows the I2C0 instance to respond to master requests and handle data reception via interrupts.
Additionally, enable the interrupt handler for the I2C0 peripheral. Configure the appropriate priority level, validate the assigned follower address, and activate the Address valid, Receive data flag to support interrupt-driven data reception.
Apply Changes
To apply and integrate the configuration changes into the project, click “Update Code.”
A new window will open to approve all the changes to the corresponding source files and ensure the new settings are reflected in the project structure. Click OK and go back to VS Code
File Structure
The MCUXpresso configuration tools automatically generate source code based on the selected settings, streamlining integration into the main application. This generated code includes initialization routines for clocks, pins, and peripherals configured in previous steps. All generated files are under board directory within the project structure.
To add the all the source files under the board folder and make the directory path only visible to this target. Modify CMakeList.txt
1. peripherals.c This file includes initialization code for peripherals configured via the Config Tools. In this example, it contains setup routines for both I2C instances and the GPIO interrupt. While the BOARD_InitPeripherals function can be used, it is often more effective to selectively integrate the generated code into specific locations within the application to align with the required execution sequence.
2. board.c When creating a project using an NXP development board, the default configuration includes initialization of debug UART pins for serial terminal communication. In this case, the UART functionality is not required, and the corresponding function in board.c will not be used.
3. clock_config.c This file contains all system clock configurations. Use the BOARD_InitBootClocks function to initialize the clock frequency and power mode settings. For this application, the system is configured to operate at 96 MHz.
4. pin_mux.c This file defines all pin configurations selected for the application, including I2C and GPIO assignments. Although UART pins are included by default, they are not utilized in this project. Use the BOARD_InitBootPins function to apply the pin settings.
Additionally, the original ST application includes a cache initialization function (MX_ICACHE_Init). In the NXP SDK, cache configuration is handled within the startup code. This can be reviewed in the SystemInit function located in system_MCU.c under the device folder.
Replace Initialization Functions
1. Clock and Pin Initialization In the main function of the NXP-based project, system clocks and pin configurations are initialized in the BOARD_InitHardware using the functions generated by the configuration tools:
BOARD_InitBootClocks
BOARD_InitBootPins
2. Peripheral Initialization Initialization code for peripherals is sourced from the peripherals.c file generated by the Config Tools. BOARD_InitBootPeripherals sets up the GPIO interrupt handler, including its priority level and NVIC configuration. And setups a 1ms SYSTICK periodic timer.
3. I2C Initialization Following this, the I2C master and slave instances are initialized along with their respective interrupt handlers and priority levels. At this stage, interrupt flags are not yet enabled; they will be activated later within the data transfer function to ensure proper sequencing and avoid premature interrupt triggering.
Source file peripherals.c includes a code snippet specifically for initializing the LPI2C0 peripheral for slave operations. This code can be selectively integrated into the main function or other appropriate locations within the application to align with the desired execution flow.
While the standalone configuration tools effectively generate the necessary initialization code, it remains the developer’s responsibility to determine the most appropriate placement of this code within the application. This decision should be guided by the operational sequence required by the specific protocol or peripheral being implemented.
For example, in I2C communication, data transfer is managed through interrupts. If the LPI2C0_Init function is used without consideration for timing, interrupts may trigger prematurely, resulting in incomplete or mismanaged transactions.
To ensure proper execution, the recommended sequence is:
Initialize the peripheral and its associated interrupt handler.
Start the I2C transaction.
Enable interrupts for both master and slave operations.
In this application, the initialization is performed within the main() function, while the interrupt flags are selectively enabled later to maintain correct timing and control.
Initialize LPI2C
To add LPI2C project settings like the slave address and data transfer length open the Kconfig file and add the following config menu
Add I2C prototypes and variables, that will be used in the I2C interrupt handlers and action functions
Replace Action Functions
4. SYSTICK Initialization The SYSTICK timer is configured to support delay operations within the application, such as controlling the LED blinking rate. Detailed instructions for initializing SYSTICK are provided in the following sections.
5. Button Polling and LED Control This functionality is implemented through a custom function that continuously polls the button input. While waiting for user interaction, the LED toggles to indicate readiness. Once the button is pressed, the LED remains steadily lit, signaling progression to the I2C data transfer phase.
6. I2C Master Handling The Handle_I2C_Master function is implemented using the driver APIs provided for the I2C peripheral in the NXP SDK. This function initiates the I2C transaction and manages the communication sequence.
Interrupt handlers for both master and slave I2C instances are derived from the peripheral initialization code. At this stage, relevant interrupt flags are selectively enabled to support the specific behaviors required by the application.
WaitForUserButtonPress
To begin customizing the GPIO interrupt handler, open the Peripherals Config Tool. From there, you can copy the auto-generated IRQ handler for GPIO, which serves as a reliable starting point. This code can then be modified to suit the specific requirements of your application.
In the VS Code development environment, paste the copied IRQ handler code into the main source file—ideally near the top—for easier access and organization.
Modifications were made to include a control variable within a while loop, allowing the application to pause execution until a button press is detected. This ensures that the program proceeds only after user interaction, aligning with the intended flow of the application.
The WaitForUserButtonPress function utilizes GPIO toggle and write operations to control the LED state, along with a delay mechanism to manage the blinking interval during the polling loop. To implement the delay, the SYSTICK timer is initialized and configured accordingly.
Additionally, a global counter variable is introduced, along with the corresponding SYSTICK interrupt handler, to support time-based operations within the application.
Within the BOARD_InitBootPeripherals() function, the SysTick_init() timer initialization was added prior to the button polling logic. This ensures that the delay mechanism is fully operational before entering the loop that waits for user input.
The finalized WaitForUserButtonPress function will include:
GPIO operations to toggle and control the LED state.
A while loop that continuously checks the button state and proceeds only upon detection of a press event.
The GPIO_* APIs are part of the NXP GPIO driver library and are used for various operations such as initialization, pin control, and interrupt handling. The macros highlighted in the code—typically shown in pink within the IDE—are generated by the Config Tools and defined in the pin_mux.h header file.
The delay functionality used in the application is implemented through a custom SYSTICK-based function, as previously described.
To explore the full set of available GPIO APIs, refer to the fsl_gpio.h header file. This file provides comprehensive support for GPIO operations, including port and pin-level control, configuration, and interrupt management.
Customizing the I2C Interrupt Handlers
To customize the I2C interrupt handlers in a manner similar to the GPIO handler, begin by opening the Peripherals Config Tool in MCUXpresso IDE. From there, locate and copy the auto-generated IRQ handler for I2C0. This serves as a foundational template that can be modified to meet the specific requirements of the application.
Repeat the same process for I2C3 by copying its auto-generated interrupt handler from the Peripherals Config Tool. This handler can then be used as a base for customization, like the approach taken with I2C0.
Consolidating I2C Interrupt Handlers
In the original ST-based project, each I2C instance utilized two separate interrupt handlers: one for standard operations and another for error handling. However, the NXP MCU used in this migration provides a single interrupt vector per I2C instance, which handles both standard and error conditions.
As a result, the functionality of the original four handlers must be consolidated into two—one for each I2C instance. This requires a careful review of the original interrupt logic to ensure that all relevant flags and behaviors are preserved in the merged implementation.
For example, the slave handler in the original project checks for an address match flag and, upon detection, verifies readiness to receive data. The equivalent behavior in the NXP environment is implemented by monitoring the appropriate status flags within the unified interrupt handler, ensuring that both address recognition and data reception are handled correctly.
Slave Handler
The I2C slave interrupt handler is triggered when the master device addresses the slave at 0x7E. Upon detecting this address match, the slave acknowledges the request and prepares to receive incoming data.
The second part of the handler manages the data reception process. It handles each byte transmitted by the master, monitors for a NACK (Not Acknowledge) condition to signal the end of transmission, and stores the received data into a designated buffer. This ensures that the slave processes the communication sequence correctly and terminates the transfer gracefully once all data has been received.
Master Handler
The I2C master interrupt handler monitors the Master Transfer Ready flag, which indicates that the peripheral is prepared to transmit the next byte of data. Upon detecting this condition, the handler checks the transmit buffer to determine if additional data remains to be sent. A counter is used to track the progress of the transmission.
Using the appropriate Master Send operation, the handler transmits the next byte and advances the buffer pointer. When the final byte is sent, the handler issues a STOP condition to signal the completion of the data transfer sequence.
Error Callback
When something goes wrong during the I2C communication, the Error_Callback function serves as an error handler doing two main actions. First, it shuts down the communication system by disabling the interrupts for both I2C instances. Second, it provides a clear visual indication to the user that an error has occur.
Handle_I2C_Master Function
The Handle_I2C_Master function is responsible for initiating and managing the I2C communication process. It begins by issuing a MasterStart command to initiate communication with the slave device at the specified address. Upon successful acknowledgment from the slave, the data transfer is handled through the corresponding interrupt routines.
This function also initializes the interrupt handlers for both the master and slave I2C instances. As previously noted, it is essential to enable interrupts after the master initiates communication to prevent premature interrupt triggering, which could disrupt the transaction sequence.
Once the data transfer is complete and the slave has received all expected bytes, the function concludes by setting the LED to a steady state—indicating successful execution and the end of the application flow.
Conclusion
Migrating an application from the STM32 development environment to the NXP MCX platform using MCUXpresso involves a structured and methodical approach. By leveraging the integrated configuration tools and understanding the functional equivalence between STM32 and NXP SDK components, developers can effectively transition their applications while maintaining performance and functionality.
This guide has outlined the key steps involved in replicating an I2C-based application, including project setup, peripheral configuration, pin and clock initialization, and interrupt handling. While the tools provide a strong foundation through auto-generated code, careful consideration must be given to the sequencing and integration of initialization and runtime logic to ensure reliable operation.
With a clear understanding of both environments and thoughtful adaptation of application logic, developers can streamline the migration process and take full advantage of the capabilities offered by the NXP MCX platform.
記事全体を表示
