Debugging External Projects with Embedded Quick Debug

This tutorial shows how to quickly debug embedded projects built outside VisualGDB using the Embedded Quick Debug feature introduced in VisualGDB 5.1.

In this tutorial we will show how to build the USB CDC sample from the Kinetis KSDK for the FRDM-KL25Z board using the CMake-based build system from KSDK and will debug it from VisualGDB without converting it to a VisualGDB project.

Before you begin, install VisualGDB 5.1 or later, get the KSDK 1.3 or later including the sample and install the Sysprogs ARM toolchain if you are missing one.

1. Locate the <KSDK>\tools\cmake_toolchain_files\armgcc.cmake file inside KSDK and edit it to use the arm-eabi toolchain instead of arm-none-eabi to match the binary names in the Sysprogs ARM toolchain:
2. Go to the toolchain binary directory and copy the make.exe file to mingw32-make.exe. This is necessary because the KSDK build scripts expect the Make tool to be named like that:
3. Open a command prompt window and add both CMake and ARM toolchain directories to PATH. Also set the ARMGCC_DIR variable to the location of your ARM toolchain, e.g.:
   
   set PATH=%PATH%;C:\Program Files (x86)\CMake\bin;C:\SysGCC\arm-eabi\bin set ARMGCC_DIR=c:\sysgcc\arm-eabi

   1 2	set PATH=%PATH%;C:\Program Files (x86)\CMake\bin;C:\SysGCC\arm-eabi\bin set ARMGCC_DIR=c:\sysgcc\arm-eabi

   
   
4. Go to the build directory of the CDC device example for the FRDM-KL25Z board (<KSDK>\examples\frdmkl25z\demo_apps\usb\device\cdc\virtual_com\bm\armgcc) and launch the build_all.bat script: Unless you built the USB device library and the KSDK platform library, the build will complation about missing libraries.
5. Go to the build directory of the platform library (<KSDK>\lib\ksdk_platform_lib\armgcc\KL25Z4) and build it by running build_all.bat there:
6. Similarly build the USB library (<KSDK>\usb\usb_core\device\lib\bm\armgcc\MKL25Z4):
7. Finally build the USB virtual COM port example again:
8. Now that the example was built successfully, you can debug it from Visual Studio using the VisualGDB Quick Debug feature. Start Visual Studio and select Debug->Quick Debug with GDB:
9. Select “Embedded firmware”, locate the ELF file built by CMake (examples\frdmkl25z\demo_apps\usb\device\cdc\virtual_com\bm\armgcc\debug\dev_cdc_virtual_com_bm.elf) and provide the following settings:
   • Toolchain: ARM
   • Device: MKL25Z128VLH4
   • Debug method: Segger J-Link
   • Initial stop: mainEnsure you set the “Save the preset as” checkbox so that the settings you enter are saved and you won’t need to enter them next time.
10. Connect your board to the USB port (ensure that the Segger firmware is downloaded into the on-board OpenSDA as described here) and press the “Debug” button. VisualGDB will program your ELF file into the board and stop at the main() function: Note the because you did not create a VisualGDB project, the IntelliSense engine won’t be able to locate all files, so functionality like go-to-definition and automatic highlighting of inactive #ifdef blocks won’t work.
11. Step through the main() function to verify that the debugging is working:
12. Now we will test out the USB functionality. Connect the second USB connector to the board and ensure that the device shows up in the Device Manager:If Windows does not recognize it, try installing the driver from the <KSDK>\examples\frdmkl25z\demo_apps\usb\device\cdc\virtual_com\inf directory.
13. Set a breakpoint in the virtual_com.c file at the line responsible for handling the USB_DEV_EVENT_DATA_RECEIVED and connect to the COM port via SmarTTY:Ensure you enable the character echoing and switch to the Text+Hex mode.
14. Try typing something in SmarTTY. The breakpoint should trigger. See how the start_transactions variable is set to ‘false’. This happens because the firmware is waiting for the DTE input and SmarTTY does not send it by default. Override it by manually setting start_transactions to 1:
15. Now if you send some bytes to the application from SmarTTY, you will see how they are echoed back by the application (shown in different color):You can easily start the debugging session again by selecting the preset in the Quick Debug window so that you won’t need to enter all the settings again.