https://community.element14.com/technologies/embedded/Embedded systems programming, design and products; also microcontrollers, programmable logic, memory, DSP and controllers. en-USTelligent Community 12https://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-4-easyl1105-exampleFri, 04 Sep 2026 09:36:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:13985249-7e45-44d2-b93a-8b9837e56ad1Jan CumpsIn this blog series, I build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. In posts 1 - 3, I created an end to end flow, from install over build to debug. In post 4: testing it out on the EasyL1105: A Dev Board for the TI ARM Cortex-M0+ L-Series with a blinky. Project and Changes I used TI's existing pwm_led_driver example for the L1105 (project is attached at the end of this post). Changes to SysConfig: different GPIO for LED: the code I attached uses PA14, to reflect my setup. I have a blue LED on PA14.. If you use an unaltered EasyL1105 board, edit pwm_led_driver.syscfg and change PA14 to PA26 on line 27. That's where one of its LEDs sits. Changes to the scripts: in CMakeLists.txt I changed the project name, and the file names of the sysconfig and .c file in launch.json, I changed the device to MSPML1105 on line 32 Debugger I used the on-board XSD110 from one of my LaunchPads. Works equally well with a standalone XSD110. On the EasyL1105, I removed all jumpers (in particular the power ones). On the LaunchPad, I removed all jumpers that connect the debugger to the controller. Then I routed Ground, 3V3, nRST, SWDIO and SWCLK from debugger to EasyL1105 J5 (SWD connector). I selected the project in VS Code CMake extension. Selected GCC toolkit. Config, Build. After that, started a debug session. All worked. The code got loaded on the MSPM0L1105, and the LED started glowing... The build script also generates a .hex firmware compatible with shabaz' python programmer. VS Code project: community.element14.com/.../EasyL1105_5F00_vscode.zip post 3: MSPM0 project with VS Code, CMake and GCC - part 3: debug part of the EasyL1105 series. all postsMSPM0L1105ccsgccMSPM0easyL1105VS Codevscodecode_composer_studiohttps://community.element14.com/technologies/embedded/m/managed-videos/151690Thu, 03 Sep 2026 14:57:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:1d1097ce-dfc0-4be6-93f6-4736b3db65f2Jan Cumpstoggle a led by directly accessing the GPIO SET and CLR registers in a debug session. Using VS Code, TI Debug Plugin, and the MSPM0 extensionMSPM0texas instrumentsvscodetihttps://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-3-debugThu, 03 Sep 2026 09:36:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:ff29cc7a-983a-42ff-8daa-e2e15ba791d4Jan CumpsIn this blog series, I build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. Post 2 covered the software build. In this post: debugging the firmware. If not done yet, open the TI Embedded Debugger plugin, and select install dependencies. It installs a version of GCC's GDB executable, support for the XDS110, drivers, and an OpenOCD install. Debugger For this post, you need a debugger. If you use a LaunchPad, you already have one ( Cheap debugger ($6) for EasyL1105 MSPM0 board ). The example is configured for TI's XDS110. Configure Environment Variables Set the GCC ARM toolchain used for debugging * . The easiest way is to override what the TI VS Code extensions put in your user file. We can do that in the Workspace settings.json file. { "folders": [ { "path": "msmp0_cmake" } ], "settings": { "cmake.cmakePath": "C:/Users/jancu/.pico-sdk/cmake/v4.2.1/bin/cmake.exe", "cmake.generator": "Ninja", "cmake.environment": { "CMAKE_PROGRAM_PATH": "C:/Users/jancu/.pico-sdk/ninja/v1.13.2/ninja.exe", "SYSCONFIG_CLI": "C:/ti/sysconfig_1.27.1/sysconfig_cli.bat" }, "cmake.configureEnvironment": { "SDK_ROOT": "C:/ti/mspm0_sdk_2_11_00_07" }, "cmake.enableTraceLogging": false, "cmake.loggingLevel": "info", "ti-embedded-debug.armToolchainPath": "c:/Users/jancu/Documents/toolchains/arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi/bin", "cortex-debug.armToolchainPath": "c:/Users/jancu/Documents/toolchains/arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi/bin" } } * the ti-embedded-debug.armToolchainPath setting is used to find the GDB executables. TI defaults it to a TI GCC toolchain installed with their TI Embedded Debug extension. I prefer to have it point to the same toolchain that I use for building the firmware. Sometimes, there are incompatibilities when you debug firmware that's built with a newer version of the GCC tools. My current setup requires me to set up a number of links to different locations. If I find the energy, I may replace that with a set of variables, and then relative paths in the scripts. Less room for mistakes, and less work when changing toolchain versions .... Debug Project Prepare a launch.json script, and place it in your project's .vscode folder: "version": "0.2.0", "configurations": [ { "cwd": "${workspaceFolder}", "executable": "${command:cmake.launchTargetPath}", "name": "Debug with TI Embedded Debug for VS Code", "request": "launch", "type": "cortex-debug", "servertype": "openocd", "configFiles": [ "./interface/xds110.cfg", "./board/ti_mspm0_launchpad.cfg" ], "searchDir": [ "C:/Users/jancu/AppData/Local/Texas Instruments/ti-embedded-debug/openocd/1.5.0.75/share/openocd/scripts" ], "runToEntryPoint": "main", "showDevDebugOutput": "none", "deviceName": "MSPM0L1306" } ] } Point the OpenOCD searchDir to script folder of where the TI Extension installed its tools (or yopur own OpenOCD install, if you have one). You can find that location in the settings.json script you just edited. Now all is ready. Press Run and Debug in the left toolbar. Select the debug configuration you just created. Then press the green button. If all is well, the debugger programs the MSPM0, then starts execution and stops on the first line of main: If you also installed TI's extension Cortex-Debug: Device Support Pack - Texas Instruments MSPM0 , you can also see (and change) the Peripheral registers. To do that, select View -> Open View -> xPeripherals: I attached my complete VS Code workspace. If you use this, you 'll have to adjust some paths in the .vscode/*.json files in the root and project folder: community.element14.com/.../workspace_5F00_vscode_5F00_mspm0.zip Post 2: MSPM0 project with VS Code, CMake and GCC - part 2: build a real project part 4: MSPM0 project with VS Code, CMake and GCC - part 4: EasyL1105 example part of the EasyL1105 series. all postsMSPM0L1105ccsMSPM0easyL1105VS CodeMSPM0L1306vscodecode_composer_studiohttps://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-2-build-and-debug-a-real-projectWed, 02 Sep 2026 20:23:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:0797ac87-8e0e-4580-aa53-9cd14948b490Jan CumpsIn this blog series, I build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. Post 1 covered the software setup. In this post: build firmware, Configure Environment Variables SDK_ROOT: SYSCONFIG_CLI: In the next post, where I use the debugger, there are a few more settings to do. Build Project We 'll need 3 files to build firmware for the MSPM0: system configuration (SysConfig) C source CMake script The first two can be taken from any Resource Explorer project. Or one of your own designs. I reused one of the projects of TI's DMA training course: DMA move a table in memory with MSPM0 The CMake file takes more work. I started from TI's example for CLang . Then made changes so that it works for the GCC ARM cross-compiler. I used AI to resolve errors and gaps. Before the traditional C build can run, the CMake file invokes SysConfig to turn your device configuration settings into C code. That part is 100% based on TI's CMake script. The remainder is more traditional: gather sources, includes, libs. Compile and Link. I added the command to also create a bootloader compatible binary (for Shabaz' Python programmer). Here is the result: cmake_minimum_required(VERSION 3.29) set(CMAKE_VERBOSE_MAKEFILE ON) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 26) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fmodules-ts") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fcommon -fno-rtti -fno-exceptions") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -ffunction-sections -fdata-sections -g -gstrict-dwarf -Wall") set(CMAKE_CXX_STANDARD_REQUIRED ON) # Cross compiling for a target system that is an embedded device set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --specs=nosys.specs --specs=nano.specs -static -Wl,--gc-sections") set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -nostartfiles -mthumb") # Create the project project( mspm0_cmake LANGUAGES C CXX # Uses the programming language C ) # Directory to the SDK used # SDK_ROOT set externally set(SDK_ROOT $ENV{SDK_ROOT}) #--------------------------------------------------------------------- # Configuration related to SysConfig #--------------------------------------------------------------------- # Find the SysConfig command line interface (CLI) command in the system path # SYSCONFIG_CLI set externally set(SYSCONFIG_CLI $ENV{SYSCONFIG_CLI}) # Directory to the generated SysConfig files set(SYSCONFIG_GENDIR ${CMAKE_BINARY_DIR}/sysconfig_generated) # SysConfig Input Script set(SYSCONFIG_INPUT_FILE_NAME mspm0_cmake.syscfg) set(SYSCONFIG_INPUT ${CMAKE_SOURCE_DIR}/${SYSCONFIG_INPUT_FILE_NAME}) # SysConfig stamp file. Described in the block comment at the end. set(SYSCONFIG_STAMP_FILE ${SYSCONFIG_GENDIR}/${SYSCONFIG_INPUT_FILE_NAME}.stamp) # SysConfig invocation command line set(SYSCONFIG_CLI_CMD ${SYSCONFIG_CLI} --script ${SYSCONFIG_INPUT} -o ${SYSCONFIG_GENDIR} --compiler gcc -s ${SDK_ROOT}/.metadata/product.json ) # Ask SysConfig what files it generates. Then categorize them. This occurs # when CMake configures the project. execute_process( COMMAND ${SYSCONFIG_CLI_CMD} --listGeneratedFiles OUTPUT_VARIABLE SYSCONFIG_GEN_FILES_STR ) string(REPLACE "\n" ";" SYSCONFIG_GEN_FILES ${SYSCONFIG_GEN_FILES_STR}) set(SYSCONFIG_GEN_CFILES ${SYSCONFIG_GEN_FILES}) set(SYSCONFIG_GEN_HFILES ${SYSCONFIG_GEN_FILES}) set(SYSCONFIG_GEN_LNKCMD ${SYSCONFIG_GEN_FILES}) set(SYSCONFIG_GEN_COMPILER_OPTS ${SYSCONFIG_GEN_FILES}) set(SYSCONFIG_GEN_LNKFILE "${SYSCONFIG_GENDIR}/device_linker.lds") list(FILTER SYSCONFIG_GEN_CFILES INCLUDE REGEX ".*\\.c$") list(FILTER SYSCONFIG_GEN_HFILES INCLUDE REGEX ".*\\.h$") list(FILTER SYSCONFIG_GEN_LNKCMD INCLUDE REGEX ".*\\.lds\\.") list(FILTER SYSCONFIG_GEN_COMPILER_OPTS INCLUDE REGEX ".*\\.opt$") # Cause CMake to run when the SysConfig input is modified, because that may # change the list of generated files set_property( DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS ${SYSCONFIG_INPUT} ) # Run SysConfig over the input script. Described further in a block comment # at the end. add_custom_command( DEPENDS ${SYSCONFIG_INPUT} OUTPUT ${SYSCONFIG_STAMP_FILE} BYPRODUCTS ${SYSCONFIG_GEN_FILES} COMMAND ${SYSCONFIG_CLI_CMD} COMMAND ${CMAKE_COMMAND} -E touch ${SYSCONFIG_STAMP_FILE} COMMENT "Running SysConfig on ${SYSCONFIG_INPUT}" VERBATIM ) add_custom_target(SysConfig_build ALL DEPENDS ${SYSCONFIG_STAMP_FILE}) #--------------------------------------------------------------------- # Configuration related to compiling #--------------------------------------------------------------------- set(PROCESSOR_OPTIONS -march=armv6s-m -mcpu=cortex-m0plus -mfloat-abi=soft -mlittle-endian -mthumb ) # These compiler options typically change as the project evolves. Because # CMake replaces an undefined variable with an empty string, one way to # disable an option is to comment out that line. set(OPTIMIZATION_OPTION -O0) set(LTO_OPTION -flto) set(DEBUG_OPTION -gdwarf-3) message(STATUS "SYSCONFIG_GEN_COMPILER_OPTS: ${SYSCONFIG_GEN_COMPILER_OPTS}") # Compiler options add_compile_options( ${PROCESSOR_OPTIONS} ${OPTIMIZATION_OPTION} ${LTO_OPTION} ${DEBUG_OPTION} @${SYSCONFIG_GEN_COMPILER_OPTS} ) message(STATUS "SYSCONFIG_GEN_CFILES: ${SYSCONFIG_GEN_CFILES}") # C files set(SOURCES ${CMAKE_SOURCE_DIR}/stub.c ${SYSCONFIG_GEN_CFILES} ${SDK_ROOT}/source/ti/devices/msp/m0p/startup_system_files/gcc/startup_mspm0l130x_gcc.c ) # Cause C files to depend on the SysConfig generated compiler options file set_source_files_properties( ${SOURCES} PROPERTIES OBJECT_DEPENDS ${SYSCONFIG_GEN_COMPILER_OPTS} ) message(STATUS "SYSCONFIG_GENDIR: ${SYSCONFIG_GENDIR}") # Directories searched for header files include_directories( ${SDK_ROOT}/source ${SDK_ROOT}/source/third_party/CMSIS/Core/Include ${SYSCONFIG_GENDIR} ) #--------------------------------------------------------------------- # Configuration related to linking #--------------------------------------------------------------------- # Linker Options add_link_options( ${LTO_OPTION} # Required when compiling AND linking ) # Directories searched for libraries link_directories( ${SDK_ROOT}/source ) message(STATUS "SYSCONFIG_GEN_LNKFILE: ${SYSCONFIG_GEN_LNKFILE}") message(STATUS "SYSCONFIG_GEN_LNKCMD: ${SYSCONFIG_GEN_LNKCMD}") set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-T${SYSCONFIG_GEN_LNKFILE}") # set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-T${SYSCONFIG_GEN_LNKCMD}") message(STATUS "SOURCES: ${SOURCES}") # Build the executable from source files in the project add_executable( ${PROJECT_NAME} ${SOURCES} ) # target_link_directories(${PROJECT_NAME} PRIVATE # "${SDK_ROOT}/source/ti/driverlib/lib/gcc/m0p/mspm0l11xx_l13xx" # ) # Libraries and linker command files target_link_libraries( ${PROJECT_NAME} PRIVATE # ${SYSCONFIG_GEN_LNKFILE} # ${SYSCONFIG_GEN_LNKCMD} ${SDK_ROOT}/source/ti/driverlib/lib/gcc/m0p/mspm0l11xx_l13xx/driverlib.a gcc c m nosys ) get_target_property(TARGET_LIBS ${PROJECT_NAME} LINK_LIBRARIES) message(STATUS "Libraries linked to ${PROJECT_NAME}: ${TARGET_LIBS}") message(STATUS "SDK uses value of assignment with 'volatile'-qualified left operand ") target_compile_options(mspm0_cmake PRIVATE -Wno-volatile) message(STATUS "SDK uses bitwise operation between different enumeration types ") target_compile_options(mspm0_cmake PRIVATE -Wno-deprecated-enum-enum-conversion) # objcopy for bootloader compatible firmware set(HEX_FILE ${PROJECT_BINARY_DIR}/${PROJECT_NAME}.hex) # POST_BUILD message(STATUS "ObjCopy utility: ${CMAKE_OBJCOPY}") message(STATUS "firmware: ${PROJECT_BINARY_DIR}/${PROJECT_NAME}") add_custom_command(TARGET ${PROJECT_NAME} POST_BUILD COMMAND ${CMAKE_OBJCOPY} -O ihex --gap-fill 0xFF ${PROJECT_BINARY_DIR}/${PROJECT_NAME} ${HEX_FILE} # COMMENT "creating .hex file ..." VERBATIM ) The TI pages that I linked to above, go in detail over each section. Use the VS Code CMake plugin to select the GCC compiler, and then config and build the project: If all is well, you should get this message after config: [cmake] -- Configuring done (4.2s) [cmake] -- Generating done (0.1s) [cmake] -- Build files have been written to: C:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake/build And this after build: [build] [4/4 100% :: 1.279] Linking C executable mspm0_cmake [driver] Build completed: 00:00:01.337 [build] Build finished with exit code 0 You can now load this firmware to your MSPM0. Either with Uniflash, or with Shabaz' Python loader . Or wait for the next post, where I'll build a VS Code launch script. That 'll allow you to step through your code, just like with TI's Code Composer Studio. Thank you for reading. post 1: MSPM0 project with VS Code, CMake and GCC - part 1: infrastructure post 3: MSPM0 project with VS Code, CMake and GCC - part 3: debug part of the E asyL1105 series. all postsMSPM0L1105ccsMSPM0easyL1105VS CodeMSPM0L1306vscodecode_composer_studiohttps://community.element14.com/technologies/embedded/b/blog/posts/mspm0-project-with-vs-code-cmake-and-gcc---part-1-infrastructureSun, 30 Aug 2026 19:37:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:4a22d15b-96a0-450f-be69-f6cc6e6818c3Jan CumpsIn this blog series, I plan to build a Texas Instruments MSPM0 example with VS Code as IDE, and CMake as build infrastructure. I'm trying to use the guidelines from TI's Using CMake with TI Clang Compilers and SysConfig . But then with GCC (version 15 for embedded arm) instead of TI Clang. And using the VS Code CMake extensions. In the first part: the infrastructure to make it work The default IDE for TI controllers is Code Composer Studio. That works right away, and has good integration with the configurator and debugger. Shabaz provided examples for Windows with Keil, Windows with GCC and Linux with GCC . Dependencies You 'll need: VS Code VS Code CMake Tools extension (released by Microsoft - install via VS Code extension button) CMake installed, preferably version 4 or higher Ninja GCC cross compile toolchain arm-none-eabi These can all be downloaded and installed separately. If you use VS Code with the Raspberry Pico extension, you will find CMake, Ninja and an Arm GCC compiler in its pico_sdk folder (on my computer: C:\Users\jancu\.pico-sdk) The next posts will also use TI's MSPM0 SDK and SysConfig tools. More on that when we need them. Create a fresh workspace, create your first project A fresh workspace is a good idea when you're experimenting with a new controller and toolset. You won't risk contaminating your existing VS Code projects Open VS Code. If you have used it before, close all windows. Then close the current workspace: File -> Close Workspace Then we make a new workspace: File-> Save Workspace As... In the dialog box, navigate to a good location, and create a folder (I used C:\Users\jancu\workspace_vscode_mspm0). Then navigate to that folder, enter a file name for the workspace (mine:workspace.code-workspace-mspm0.code-workspace) Then Save Let's add a folder for our first project to the workspace: File -> Add folder to workspace. In the dialog box, navigate to that workspace you just created, and create a new folder there (I used: msmp0_cmake). Select it, then Add use of AI: I used Google AI to look up compiler settings for the MSPM0 architecture (see image at the top of the post). It also helped to resolve several build errors Install and configure VS Code CMake extension Click on the VS Code Extensions icon, and search for CMake Tools. Install it. If your CMake and Ninja executables are not on your path, you can define them in the settings. If tcmake.exe and ninja.exe are on your path, you can skip the steps. Select the Manage cogwheel, and select Settings. Select the Workspace tab. Extensions -> Cmake Tools Set the path to your cmake.exe in Cmake Path: And add Ninja's executable as CMake Environment variable CMAKE_PROGRAM_PATH. Minimal CMake File and Test Code I lean heavily on TI's notes here. The C source is the same. The CMake file is adapted to GCC. And I left out the parts that will be covered in a follow up post. The goal is to have a successful build. Create a binary without errors or warnings. stub.c: int main() { return 0; } CMakeLists.txt: cmake_minimum_required(VERSION 3.29) set(CMAKE_C_STANDARD 11) set(CMAKE_CXX_STANDARD 26) set(CMAKE_EXPORT_COMPILE_COMMANDS ON) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fmodules-ts -fcommon -fno-rtti -fno-exceptions --specs=nano.specs -Wl,--gc-sections") set(CMAKE_CXX_STANDARD_REQUIRED ON) # Cross compiling for a target system that is an embedded device set(CMAKE_SYSTEM_NAME Generic) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} --specs=nosys.specs -Wl,--gc-sections") # Create the project project( stub # Project is named stub LANGUAGES C CXX # Uses the programming language C ) #--------------------------------------------------------------------- # Configuration related to compiling #--------------------------------------------------------------------- # Compiler options which specify the variant of the Arm processor in the # system. set(PROCESSOR_OPTIONS -march=armv6s-m -mcpu=cortex-m0plus -mfloat-abi=soft -mlittle-endian -mthumb ) # Build the executable from source files in the project add_executable( stub # Executable is named stub stub.c # Has one source file nofilesystem.c # temporary function definitions until we add sdk libs ) I also created a C file to define a few of dummy filesystem operations. Else, the linker throws warnings for a set of missing functions. Once the MSPM0 library is linked in (next post), we can remove this file. nofilesystem.c: #include int _close(int file) { (void)file; return -1; } int _fstat(int file, struct stat *st) { (void)file; st->st_mode = S_IFCHR; return 0; } int _isatty(int file) { (void)file; return 1; } int _lseek(int file, int ptr, int dir) { (void)file; (void)ptr; (void)dir; return 0; } int _read(int file, char *ptr, int len) { (void)file; (void)ptr; (void)len; return 0; } int _write(int file, char *ptr, int len) { (void)file; (void)ptr; (void)len; return len; } Use CMake Tools to configure the project and run a build Open CMake Tools. Select your project folder. If your arm cross is on the path, you can directly select it as a kit in the Configure node. If not, press the Select a Kit pencil, and scan recursively for toolchains. In the dialog that pops up, navigate to the root directory of your GCC arm-none-eabi kit. If you use the Raspberry Pico extension for VS Code, you will find at least one GCC version in its toolchain subfolder. Complete configuration by pressing the Configure button: You should see output similar to this: [main] Configuring project: msmp0_cmake [proc] Executing command: C:/Users/jancu/.pico-sdk/cmake/v4.2.1/bin/cmake.exe -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_C_COMPILER:FILEPATH=c:\Users\jancu\Documents\toolchains\arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-gcc.exe -DCMAKE_CXX_COMPILER:FILEPATH=c:\Users\jancu\Documents\toolchains\arm-gnu-toolchain-15.2.rel1-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-g++.exe --no-warn-unused-cli -S C:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake -B c:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake/build -G Ninja [cmake] Not searching for unused variables given on the command line. [cmake] -- Configuring done (0.0s) [cmake] -- Generating done (0.0s) [cmake] -- Build files have been written to: C:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake/build Then build the project: The output should have no errors and warnings [main] Building folder: c:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake/build [build] Starting build [proc] Executing command: C:/Users/jancu/.pico-sdk/cmake/v4.2.1/bin/cmake.exe --build c:/Users/jancu/workspace_vscode_mspm0/msmp0_cmake/build --config Debug --target all -- [build] [2/3 33% :: 0.127] Building C object CMakeFiles/stub.dir/stub.c.obj [build] [2/3 66% :: 0.144] Building C object CMakeFiles/stub.dir/nofilesystem.c.obj [build] [3/3 100% :: 0.262] Linking C executable stub [driver] Build completed: 00:00:00.319 [build] Build finished with exit code 0 Let's check if the executable is built: yes In the next post, I try to set up linking with the SDK libraries. And then a first real project... post 2: MSPM0 project with VS Code, CMake and GCC - part 2: build a real project part of the E asyL1105 series. all postsMSPM0L1105ccsMSPM0easyL1105VS CodecmakeMSPM0L1306vscodecode_composer_studiohttps://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237960Sat, 29 Aug 2026 14:35:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:e9a79583-e55f-487d-915c-15db792a6eecbeacon_dave[quote userid="121623" url="~/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237959"] is this because you didn't use any or because E14 lost it ?[/quote] Probably because the Code widget defaults to 'Text' and needs to be set to 'C'https://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237959Sat, 29 Aug 2026 14:13:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:88a72424-5176-46bc-be7c-b3c3ff9d496dmichaelkellettAn unsigned variable can reach zero, but it can't be negative. Change for(times = 10; times >= 0; times --) to for(times = 10; times > 0; times --) or better to for(times = 0u; times =0 trap) I find your code almost impossible to follow because there is no indentation - is this because you didn't use any or because E14 lost it ? It would be good if you could repost it with indentation if you can: (I did this in Notepad++ set for C language) The indentation style is based on https://barrgroup.com/sites/default/files/barr_c_coding_standard_2018.pdf I'll take another look then and see if I can work out what is happening. MKhttps://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237958Sat, 29 Aug 2026 12:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:c93fae07-ebe6-40f4-bc72-18e654f5cbd8madthescientistI named it unsigned since most examples i found in the web uses unsigned, i did not know that it prevents it to reach zero.https://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237957Sat, 29 Aug 2026 12:55:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:bf5a4aea-eefc-4ef5-86bb-960788b4dc09madthescientistYes, even pins have their names on them. Watchdog is off.https://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237953Fri, 28 Aug 2026 14:36:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:8d0b161f-802f-4ccf-977f-88eba8c38293Andrew JDo you have a routine that sets up the input/output pins and the timers?https://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazy/237952Fri, 28 Aug 2026 05:14:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:baf25ee7-bd4b-4f9f-a402-362817d89e75vmateI don't quite fully understand what you did so far and what the goal would be, but I can see several problems: The for loop you made is an infinite loop, because 'times' is unsigned, aka. it can never be lower than 0, and the condition for the for loop to finish is 'times' being lower than 0. Also, the ' if ( counter % 3 == 0 )' part increments 'times', and the for loop decrements it, so they are actively fighting one another. You might've intended for that to happen, but this is not generally a good idea to do: the rule of thumb is to use a for loop if you already know how many times you want the loop to run, or use a while loop if you don't. Another problematic part is the speed of execution. You're checking the counter's value in the for loop in multiple places, but that loop will execute many thousands of times faster than the counter's increment speed. If I were you, I'd probably start from scratch, and ignore the hardware timer for now. Have a big while(1) loop with a __delay_ms(1 0 ); at the end, and just increment your own counter somewhere. Getting an Arduino, and going through the Arduino IDE's examples(like 'Blink without delay()') to learn the logic and program flow for such a microcontroller would probably be the ideal path, as the learning curve is much gentler there.https://community.element14.com/technologies/embedded/f/pic-micro-forum/57220/fizzbuzz-in-pic16f877a-driving-me-crazyFri, 28 Aug 2026 00:38:00 GMT93d5dcb4-84c2-446f-b2cb-99731719e767:356601c7-c4e2-4d36-9ac5-3d38751419cdmadthescientistI am trying to create a firmware for Pic16f877A, using mplab 6.15 on gnu/linux and pickit 3. After finding out code examples in C language i could try and test parts to build a working piece of source code for it. However, i am finding myself at odds whenever i do wish to get actual work done. I do wish to drive some leds on an off in sequences, sometimes turning on one, off other several times and holding them off some minutes to do it back. I could accomplish part of it using something called "fizz buzz" example and reading ticks from Timer 1's prescaler. My C and PIC knowledge is not yet the best. The major problem i am struggling with is that, i can get 2 leds toggling one after the other, but if i try to get that within a FOR cycle, it either never stops if i do not add any code at FOR's end, or if i add code, it inmediatly jumps to it avoiding to toggle the leds altogether. If i code them off after for() they stay off, if i code them on after for, they stay offf. The source code i am in trouble with is this one: void MainProgramme(void) { /*Essential Variables Are Declared Here*/ Led3 = 0; //Seems It Has To Be Turned Explicitly Off Before Anything... unsigned int tick = 0; //A Common Variable For Measuring Timer0 Ticks unsigned int activations = 0; //This Is For Counting Movements. unsigned int times = 0; //This Is For Counting SubFunction Executions. unsigned int blinks = 0;// This Is For Programme Led Blink Timer 0 Overflow Counting. unsigned int counter = 1; /*The Function Actually Starts Here*/ while(Button1 == 0) //Checks If Button1 Is Depressed Aiming Towards Turning Off The Machine { while(Run == 0) //Checks If Run Button Is Depressed Toggling Between Work Or Pause { /******************************************************************************************************/ /*Main Led Stays Blinking At Around 2hz While The Procedure Takes Place If Not Paused*/ tick++; // Check if Timer0 has overflowed if(TMR0IF == 1) { TMR0IF = 0; // Reset the flag immediately blinks++; // 7 overflows ~ 458ms (close to 0.5s for 1Hz toggle) if(blinks >= 266) { MainLed = ~MainLed; // Toggle LED on RB0 blinks = 0; // Reset counter } /**********************************************************************************************************/ if(Led7 == 0) { //-------------------------------------------------------------- while(Switch2 == 0) { Blink2 = 0; Blink1 = 0; Led3 = 0; // Timer 0 For Programme Led Blinking. IT WORKS, AVOID BREAKING. // Check if Timer0 has overflowed if(TMR0IF == 1) { TMR0IF = 0; // Reset the flag immediately blinks++; // 7 overflows ~ 458ms (close to 0.5s for 1Hz toggle) if(blinks >= 266) { MainLed = ~MainLed; // Toggle LED on RB0 blinks = 0; // Reset counter } } Led6 = 1; } Led6 = 0; } // Main Programme Led Blink Ends Here. AVOID TOUCHING THIS PART, IT WORKS. //------------------------------------------------------------------------ if(Led7 == 1) { while(Switch1 == 0) { Blink2 = 0; Blink1 = 0; Led3 = 0; // Timer 0 For Programme Led Blinking // Check if Timer0 has overflowed if(TMR0IF == 1) { TMR0IF = 0; // Reset the flag immediately blinks++; // 7 overflows ~ 458ms (close to 0.5s for 1Hz toggle) if(blinks >= 266) { MainLed = ~MainLed; // Toggle LED on RB0 blinks = 0; // Reset counter } } Led6 = 1; } Led6 = 0; } // Main Programme Led Blink Ends Here. AVOID TOUCHING THIS PART, IT WORKS. //------------------------------------------------------------------------------------------------ //Timer 1 For Blink Led Timings while(Switch1 == 1 || Switch2 == 1) { /************************************************************************/ /*Programme Led Seems To Be Blinked Locally*/ // Check if Timer0 has overflowed if(TMR0IF == 1) { TMR0IF = 0; // Reset the flag immediately blinks++; // 7 overflows ~ 458ms (close to 0.5s for 1Hz toggle) if(blinks >= 198) { MainLed = ~MainLed; // Toggle LED on RB0 blinks = 0; // Reset counter } } /*************************************************************************/ //This Is Timer 1 Setting leds Timings.Timer 0 Sets Programme Led Blinking if (PIR1bits.TMR1IF) { // Check if Timer1 overflowed PIR1bits.TMR1IF = 0; // Clear flag TMR1H = 0x00; // Reload timer TMR1L = 0x00; counter++; if (counter > 200) counter = 1; // Loop 1 to 100 } if((MainStrenghtRedLed == 0) && (MainStrenghtGreenLed == 1)) { for(times = 10; times >= 0; times --) { if (counter % 3 == 0) { times = times + 1; Blink1 = 0; Blink2 = 1; } else if (counter % 5 == 0) { Blink1 = 1; Blink2 = 0; } else if (counter % 7 == 0) { Blink1 = 0; Blink2 = 1; } else if (counter % 9 == 0) { Blink1 = 1; Blink2 = 0; } else if (counter % 11 == 0) { Blink1 = 0; Blink2 = 1; } else if (counter % 13 == 0) { Blink1 = 1; Blink2 = 0; } else if (counter % 15 == 0) { Blink1 = 0; Blink2 = 1; activations--; } } //It's suposed to perform this FizzBuzz routine a couple of times and stop, then again for some times. Problem is: it never stops. If i do add any code after the For() it actually jumps to it. } }Led6 = 1; //End Of While /*******************************************************/ } /*******************************************************/ } }__delay_ms(100); PowerOff(); }