Public:Building and Debugging Code

Getting Started

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

Creating a new MCUXpresso Project

Generally there is one project per board. To do so:

1. You should use the appropriate skeleton project for your chip as a starting point.
   1. For ISC made boards that should be the mbed1549_skeleton (Argo) or mbed15x9_skeleton (Brizo or Calypso)
   2. For older boards from CalSol you may need the mbed11c14_skeleton
2. In the project explorer right click on the appropriate skeleton and select "Copy"
3. Right click in the Project Explorer and "Paste"
4. At the "Copy Project" Dialog, name your project. Ensure this is unique, otherwise MCUXpresso won't let others import it (and we can't tell projects apart easily!)
5. Uncheck "Use Default Location"
   1. Click "Browse"
   2. Create a new folder in the repo for the project. The name does not matter but it is generally best to make it the same as the project name
      1. for example if you were making a project called "Dash", create a folder called "Dash" in b-fw and select this folder
   3. Select the new folder and press "ok"

Done! You can now work on your new project!

Building

Remember to close projects that are not needed

1. At this point you should have all of the projects imported into your workspace
   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.
      1. To close a project, right click on it in the Project Explorer and click Close Project
2. Set all build configurations (mbed, common, <project_name>) to whatever microcontroller is being used
   • *Right click on each project > Build Configurations > Set Active > <correct microcontroller>

3. Make sure the linker script location for your project is set correctly (on your project)

1. Right click on <project_name> (NOT mbed or common) > Properties > C/C++ Build > Settings
2. In the "Tool Settings" tab go to MCU C++ Linker > Managed Linker Script
3. Make sure that you have:
   1. Script name: chipname.ld such as: "LPC1549.ld" (Argo-FW) or "LPC15x9.ld" (B-FW or Calypso)
   2. Script path: "..\..\mbed\libraries\mbed\targets\cmsis\TARGET_NXP\TARGET_LPC15XX\TOOLCHAIN_GCC_CR" (all cars)
   3. (If you can't change these uncheck "Manage Linker Script")

4. Make sure the compiler language settings are set to the right thing (on mbed, common, and <project_name>)

1. Right click on each 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)

5. Build the project (Windows: ctrl+b / Mac: cmd+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 as you probably won't be changing it.

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

Flashing/Debugging

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

Setting up your projects & MCUXpresso settings

1. With MCUXpresso closed set up MCUXpresso to be able to see the DAP42 Debugger (if you're using the large, inefficient LPC-Link2 then you don't have to follow this step)
   • *If you're using the small ones that that's the DAP42
   1. Navigate to
      • **Windows: [your hard drive root directory/nxp/MCUXpressoIDE_xx.x.x_xxx/ide/bin/Scripts/probetable.csv
      • **Mac: Applications then MCUXpressoIDE_xx.x.x_xxx/ide/bin/Scripts/probetable.csv
   2. Open that file in Notepad or Notepad++ (NOT EXCEL) or Text Edit on Mac
   3. Add this line to the bottom: 0x1209, 0xDA42, 64, 1, 0, 0, 0, "", 0x0000, -1 (and a new line after it)
   4. Save and close the file
      1. you may have difficulties with permissions editing this file, is this occurs, ask for help and update this page with instructions.
2. Open MCUXpresso and build your project
3. Create the debug configuration (you'll only do this once per project)
   1. Right click on your project (NOT mbed or common, but your project) > Debug As > Debug Configurations... (or triangle next to green bug)
      • 
   2. Double click on C/C++ (NXP Semiconductors) MCU Application to create a build configuration
   3. Leave Project Name as default
   4. Under "C/C++ Application", click Browse... and navigate to the project's folder inside the repository. The file will be located in that folder (in the repo) at LPC15xx\projectname.axf
      • 

1. Try clicking Debug (the bug icon in the toolbar)
   1. If all goes well you'll see this dialog:
      • 
2. You are now debugging. The debugger works just like it does in Eclipse which is basically gdb. Except, if you try to use more than 4 breakpoints, it will probably crash and complain "resource not available."
3. Before disconnecting the debugger from board, click the "Terminate Debug Session" button (red square) or "Terminate All Debug Sessions" (red square overlapping another red square)
   1. Don't leave an unpowered DAP42 plugged into your board as it will pull the ISP/RESET pins which will prevent your board from running

Debugging after going through setup for a project

1. Build your project without errors (if there are errors it won't write the <project_name>.axf file)
2. Click on the bug icon: the green one, but the purple one will probably also work so don't worry too much)
3. That's it. It should load the configuration, find the debugger, upload the code, and start the session without any further input from you
4. Before disconnecting the debugger from board, click the "Terminate Debug Session" button (red square) or "Terminate All Debug Sessions" (red square overlapping another red square)

Notes and 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 4 in Building.

• Did you get your code to upload, but now it's not letting you upload code? Make sure that you've ended any previous debugging sessions before trying to upload code again (you can either right click on an instance and terminate it or terminate all from the top menu in MCUXpresso). Sometimes, if you unplug debuggers with active debug sessions MCUXpresso may get very confused and not allow you to end active debug sessions. You will need to restart MCUXpresso (or sometimes your whole computer) to fix that.
  • Was the device working previosly but it's not working any more? If you flashed bad code and now are getting error "Target error from Commit Flash write: Ep(08). Cannot access core regs when target running." you can try using the ISP pins to force boot mode. This procedure is not very reliable but if you try it enough times it'll work. First you will probalby have to solder wires to ISP0 and ISP1 generally the easiest way to do this in my experience is to solder wires to the resistors that pull up ISP1 and ISP0 on the sides that connect to the mcu. Here r the steps:
    • Disconnect board from everything
    • Connect the wires you have connected to ISP0 and ISP1 to GND on the board.
    • Power the board from USB
    • wait a second or two
    • disconnect ISP1 and ISP0
    • Connect debugger
    • Flash code
• Are you getting an error saying cannot find -lcommon or similar? Make sure that the active build configuration for common and mbed for the same microcontroller as your project and that they have the correct dialect selected. You could also try removing mbed and common from the MCUExpresso workspace then copying the .cproject and .project files from another working branch into both common and mbed, then finally running the shell script and re-importing mbed and common into the workspace.
• Does it say cannot find -lcommon -lmbed close MCUExpresso, and delete .cproject and .project files in common and mbed then redo the setup process for these files.
• Does it say cannot find -lzephyr-common remove zephyr common from Properties > MCU Assembler > General
• Is the Debugger crashing on upload, with red messages saying that GDB crashed and can't be relied on? Try opening the breakpoints tab and right click "delete all" to make sure there aren't random ones saved. Also setting too many breakpoints can crash the debugger too.
• Is your board hard-faulting on debug? Check the .cproject file and try reverting to an earlier version if things are really ugly. Don’t sink 6 hours into attempting to fix the versioning by committing more changes like we did.
• Is the debugger not working and the red LED on it is lit up? It’s probably stuck in some weird state. Unplugging it and plugging it back in will usually fix it.
• Is the debugger really really not letting you upload code, even though it appears to be okay? You may have accidentally disabled the SWD/JTAG pins on the microcontroller, blocking communications. Try holding down PGRM and RESET on your board to force it to go into the on-chip bootloader, which is always able to talk to the debugger.
• The debugger does not provide power to your board. Make sure it’s powered on…
• If you need to change the processor (LPC1549 vs LPC11C14), you can do so by right clicking the project and selecting C++ Build > MCU Settings
  • Note that because of the way that the mbed libraries map the interrupt vector table to let you dynamically set interrupt handlers, there are 512 bytes of RAM that are dedicated to the table
  • When you change the processor, you may need to adjust the RAM region to start offset by 512 bytes (0x10000200 instead of 0x10000000) and to be 512 bytes smaller (0x1E00 instead of 0x2000) for the LPC11Cx4. Otherwise the linker may attempt to place variables in the space reserved for the interrupt table and you may see variables getting corrupted.
• The LPCXpresso board is a combination of the LPC-LINK debugger (which you want to use to program your board) and a target board containing a microcontroller. To use the LPC-LINK to program your board, you need to desolder the traces between the two rows of nine pins in the middle of the LPCXpresso board.
  • For extra mechanical fun, you can also dice the board into two pieces, where the cut point is the line of traces that you desoldered.
• If all else fails, try restarting LPCXpresso / plugging in / unplugging the board + debugger board, etc. Actually, this is usually a good place to start.

If you have a macOS Catalina/Big Sur and cannot flash the board try these steps and talk to Priyal if you can't figure it out:

• Make sure the MCUXpresso version you are on is up to date (latest one that worked was 11.3).
• Try deleting your debug configuration and making a new one. Making sure its for whichever microcontroller you are trying to flash to.

From a list of "KnownIssues.txt" within the MCU documentation: "Probe discovery / Launch configuration generation can take a long time on some Mac OS X 10.12 (Sierra) installs, due to an OS / Java issue with the java.net.InetAddress.getLocalHost() function. This can be fixed by modifying your "/etc/hosts" file (see the "MCUXpresso IDE Installation Guide" for more details)." Basically you should follow these steps

Follow these steps if you are on a macOS Sierra (it may help if you are on a later macOS - worth a try)

• It might be that the redlinkserv network is being blocked by a firewall, make sure you disable the firewall.

Run into other issues not found here? Add to this list to help others!

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. The error text when trying to debug was a popup saying Socket exception: connection reset or something similar, and the details were a whole list of things including Java code locations. This problem is probably not with the drivers. The easiest fix was to install MCUXpresso 10.1.0 instead of 10.1.1. It may work with other earlier versions as well but hasn't been tested yet. Also make sure to restart your computer after attempting any changes to MCUXpresso versions and driver installs.

Linux Mint (and likely other versions) do not properly configure the permissions (and sometimes device type) of the DAP42 probe.

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)

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.

Future

• Support program via CAN

Credit

This was made using the original LPCXpresso guide from Derek Chou (of Calsol and ISC) here: Google Docs Link