Changing MCUs in GCC Arm Embedded (Cmake) Tool chain

[HeMyFAE]

Dear Cmake Tool,

I plan to use the LPC54606  and downloaded the SKD but it came with pre-configured with the LPC54608.

How do I change the MCU from one flavor to another?

Thx,

hy

[clarkjarvis_yah]

First, a few concepts around the MCUXpresso SDK...

The SDK includes all the drivers and header files for a selected devices.  The SDK will also include middleware that was selected during the build process. 

Each NXP device has a "recommended board", there are instances where the recommended board features a different device that the one selected.  Often times this is a superset device or some other software compatible device.  Examples provided in the SDK are board specific, so they will target the specific board hardware and populated device.  The included examples are developed and tested on functional development boards. 

Porting an SDK example to custom hardware featuring a different device than the one included on an NXP development board will take some effort, but the structure of the SDK should help make this a very doable process.

For this specific example, the full LPC54606 SDK will include the SDK files for the LPC54606 device and will include the SDK files for the LPC54608 device (these are included in order to support the LPCXpresso608 board, that is the recommended board for the LPC54606).

The example projects are based on boards, since that is how NXP tests and releases the example projects.  There are no example projects provided for devices only.  The MCUXpresso IDE does have templates that it uses to create empty (or “hello world”-like) projects for devices.  However, there is not an equivalent project generator provided by NXP for GCC / CMake.

The folder structure of the SDK is very consistent and this will allow for the CMakeList file to be relatively easy to convert to a new device.

General steps for converting a CMake project for LPCXpresso54608 to a custom LPC54606 board:

1. Copy an existing project from the full SDK folder <SDK_Path>/board/lpcxpresso54608/lwip_examples/lwip_ping
2. Paste into <SDK_Path>/board/lpcxpresso54608/lwip_examples/lwip_ping_my_board
   It is possible to place into a new directory structure with such as
   <SDK_Path>/board/my_board/lwip_examples/lwip_ping,
   but care must be taken to ensure the directory depths are consistent, or the relative paths in the CMakeList.txt will need to be updated accordingly.
3. Replace all references of the package name, device name, and linker files (in that order)
   • Replace “LPC54608J512ET180” with “LPC54606J512ET100”
   • Replace “LPC54608” with “LPC54606”
   • Replace “LPC54608J512_flash.ld” with “LPC54606J256_flash.ld”  and add the file to the project
     (found in <SDK_Path>/devices/LPC54606/gcc)
4. Open the standalone MCUXpresso Config Tools (not the version integrated with MCUXpresso IDE) and “Create a new configuration in the toolchain project”
   • Browse to the newly copied project
     <SDK_Path>/board/lpcxpresso54608/lwip_examples/lwip_ping_my_board/bm/armgcc
   • The Config Tools will parse the CMakeList file to id the processor and config files, then parse the config files to restore the settings
5. Change Processors in the Config Tools
   • The Config Tools will recognize that the processor in the CMake (that we edited to reference the LPC54606) does not match the config file (LPC54608, which is referenced in the config files), you can right click the error and have the tool config the processor and package type to match the CMake file.  Or use the File -> Switch processor to make the change manually
   • In the lwip example, the tool was not able to automatically reassign the pins due to the package differences, but I was able to go through and reassign each function to the a suitable pin.  You would align this setup to your specific hardware anyways.
6. Update and Generate the new Pin / Clock Config files.
7. Additionally grep through the code in the project for any references to “608”.  This will depend on the application, my search of the lwip_ping example resulted in only one match that did not impact the application directly.

The application should compile at this time.  Depending on the example application you will likely need to review how the board.h file was used and update the defines to match your specific hardware.