Public:Building and Debugging Code

Getting Started

• Have the code downloaded locally from Github. See: ((Github Setup))
• Have MCUXpresso installed and ready to go. See: ((MCUXpresso))

 

Building

1. At this point you should have all of the proper projects imported (if the projects don't seem to be imported, try that again).
2. Open the required projects (and close all others)
   1. The ONLY things you should have open are:
      1. mbed
      2. common
      3. <project_name>
   2. Close everything else that is open. You will be very sad if there are build error in other projects that make yours fail.
3. Set all build configurations (mbed, common, <project_name>) to whatever microcontroller is being used (probably LPC1549).

+

File:68 #Make sure the linker script location for your project is set correctly (on your project).

1. 1. Right click on the Project you are trying to build > Properties > C/C++ Build > Settings
   2. In "Tool Settings" go to MCU C++ Linker > Managed Linker Script
   3. Make sure that you have:
      1. Script name: -+LPC1549.ld+-
      2. Script path: -+..\..\mbed\libraries\mbed\targets\cmsis\TARGET_NXP\TARGET_LPC15XX\TOOLCHAIN_GCC_CR+-
      3. (If you can't change these uncheck "Manage Linker Script")

+

File:69 + 

1. Make sure the compiler language settings are set to the right thing (on mbed, common, and your project) If you don't
   1. Right click on Project > Properties > C/C++ Build Settings>Settings
   2. In "Tool Settings" go to MCU C++ Compiler > Dialect
   3. Language standard settings should be:
      1. For common: -+ISO C++11 (-std=c++11)+-
      2. For mbed: -+ISO C++11 (-std=c++0x)+-

+

File:70 #Build the project (ctrl+b). This will take a while (1-4 mins), especially when doing a full build for the first time. Future, incremental builds, should be faster as you won't need to recompile mbed (the OS) each time.

1. If everything went well, then you now have a compiled binary file that you need to program/debug the microcontroller.

Flashing/Debugging

The way we flash code and debug is the same. Flashing code is just starting a debug session and then ending it right away. The steps to do so are:

Before you can debug you need to have a debugger configured. If using an LPC-Link2 it will work out of the box (usually) so you have no set-up. On ISC we typically use the DAP42 debugger (it is cheaper and more-reliable). Configuration instructions are below.

1. Create the debug configuration (you'll only do this once per project)
   1. Select your project (NOT mbed or common, but your project) and open "Debug Configurations"

File:73 ##Double click on C/C++ (NXP Semiconductors) MCU Application to create a build configuration

1. 1. Name it appropriately (i.e. you don't want a bunch of configs called "new")
   2. Browse for the C/C++ Application you just built. It will be located in your project folder (in the repo) at -+LPC1549\projectname.axf+-

File:74 #Try hitting debug (the bug icon in the toolbar)

1. 1. If all goes well you'll see this dialog:

File:75 #You are now debugging. The debugger works just like a it does in Eclipse which is basically gdb. Except, if you try to use more than 4 breakpoints, it will crash and complain "resource not available."

 

Setting up the DAP42 debugger

To use the custom DAP42 debugger from [1]:

• The default probe rules do not detect this device. To use this probe you will need to modify the probe table at: nxp/MCUXpressoIDE_xx.x.x_xxx/ide/bin/scripts/probetable.csv
• Open the probe table in notepad or notepad++ (NOT EXCEL) and add this line to the bottom: -+0x1209, 0xDA42, 64, 1, 0, 0, 0, "", 0x0000, -1+-
• Select DAP42 when debugging

 

Common Problems

Shadows template parm 'int N' and some other build errors that complain about types

You probably didn't set the compiler language correctly. Double check step 5 in Building.

Uncommon Problems

If you have a Lenovo non-ThinkPad device, or maybe something else weird running Windows 10, you might run into the debuggers not working even if you've set up everything correctly. We've only had one team member with this problem so far but happened to them on 2 devices so it's worth mentioning in here. The error text when trying to debug was a popup saying "Socket exception: connection reset" or something similar, and the details would be a whole list of things including Java code locations. This problem is not with the drivers, surprisingly, but with MCUXpresso. Or at least, the fix was to install MCUXpresso 10.0.0 instead of the version just before 10.2. It may work with another version as well but hasn't been tested yet. Also make sure to restart your computer after attempting any changes to MCUXpresso versions and (if you want) driver installs. Another thing that may have helped is forcing Windows to install a nice driver for it using Zadig, a tool which you can run without installation.

Linux Mint (and likely other versions) do not properly configure the permissions (and sometimes device type) of the DAP42 probe. The easiest way to solve this is by adding 

||ATTRS{idVendor}=="1209", ATTRS{idProduct}=="da42", ENV{ID_MM_DEVICE_IGNORE}="1", MODE="0666"||

to a udev rule (e.g. I recommend adding it to the file "/etc/udev/rules.d/12-dap42.rules"). REBOOT AFTER ADDING THIS FILE. This issue can be seen as a debugging error with the following message:

||"Server OK but no connection" to probe 1 core 0 (after 3 attempts) - Ee(36)||

Future

• Support program via CAN

 

Credit

This was made using the original LPCXpresso guide from Derek Chou (of Calsol and ISC) here: https://docs.google.com/document/d/1UbqKGVPCTO-VmLjGza0Km96y2tYtIO1zAWrmcexgvYg/