The board support package (BSP) is at the core of the ModusToolbox software. We provide a BSP for each of our kits, and it makes a lot of magic happen. This includes:

  • A hardware configuration file (default design.modus) that sets up clocks, peripherals, and pins
  • Header files with common aliases and macros to abstract board functionality
  • Linker scripts and startup code for the part on the kit
  • Files that add libraries required to support the board

Kits are great. Along with code examples, they give you a reference platform for a particular chip series to get you started. At some point, however, you move from our kit to your design. The BSP is so central to the ModusToolbox process that it’s quite likely you will create your own for your hardware. You can tweak an existing BSP, but this article is about the more common use case, you want to roll your own, a custom BSP. The steps you need to follow are actually quite straightforward, and most of them are simple. A blog is not a detailed “how to.” So when you do this for real, use these two resources:

I recommend both! You’ll get a slightly different flavor; one is documentation, the other is more a “how to.” Each gives you the details you need and also answers the critical question, now that I have my own BSP, how do I use it? You’ll want to know that answer.

I’m going to give you an overview of how it works and what to expect. But do read the docs when you get started for real. (In ModusToolbox v2.1 this worked a little differently, so read the documentation for sure in that case.)

Step 1, you create an application based on one of our examples, which of course starts with an existing BSP. Simple. You can start with a generic, lowest-common denominator BSP and add functionality, or start with a BSP close to what you want, and tweak it. Either way works.

Step 2, issue a simple make command from the application directory to generate a new BSP for a new part. I described our make system in It’s Make Time. The ModusToolbox make system has a target to create a new BSP:

    make bsp TARGET_GEN=<MyBSPName> DEVICE_GEN=<PartNumber>

Here’s the rub. When that process is done, the BSP is not ready for your part. In fact, you may even see errors generated by that make command. You get the right startup code and linker script for your new part, but the board configuration matches what was in the original BSP. It is unlikely that that will work for your hardware. You are almost certain to use your own pins in your own way for your own subset of peripherals configured the way you want. It is impossible for us to finish the job for you because we don't know your board.

So, Step 3, adapt your new BSP to fit your design. This is where the work is.

In a nutshell, you use the Device Configurator to adjust the clocks; enable or disable a peripheral; configure the peripherals; perhaps set up DMA the way you want. You get the idea. Fix the errors (if there were any) and adjust any other parameters to set up your hardware correctly. When you save your work, the Device Configurator generates all the code required to configure the part.

The other typical task is to add, update, or remove libraries where your board differs from the standard BSP you started with.  That’s easy. Again, check out the KBA for background on this, and read the documentation.

If you need to customize the startup code or linker scripts, you can do that of course. It’s your BSP.


So, creating a custom BSP is not automatic, but it is straightforward. You use a simple make command to create a copy of one of our BSPs. You then ensure that the low-level “stuff” is correct for your design. Hey, they’re paying you for a reason. In all cases, the documentation is your friend.

We also eat our own dogfood around here, and we have some ideas for making this simpler. Your feedback or suggestions are always welcome in these parts.

Cheers, and happy BSP-ing.