In this article, we will examine some of the more popular Cortex-M hardware debug pods (also called debug probes), which are hardware devices necessary for debugging firmware on a Cortex-M based MCU.
Overview of Debugging
In the “good old days”, debugging an embedded system often meant the judicious use of printf to output debugging messages to a terminal. Fortunately, modern MCUs now come with hardware debug support that makes it easy to implement the core debugging features such as instruction breakpoints, and memory access. In the Cortex-M core specification, ARM Inc. includes a Coresight Debug Access Port (DAP) for just such purposes. As the DAP is present in all the Cortex-M base MCUs, this means that they all can provide debug support.
A strength of Cortex-M based MCUs is that the core CPU is designed by ARM Inc., while silicon vendors license the core design and then put their own I/O peripherals around it. With all major MCU vendors supporting the Cortex MCU, embedded designers have a large number of MCUs to choose from, while able to reuse their existing knowledge of the CPU information.
To make the software a bit more manageable, ARM has published the CMSIS (Cortex Microcontroller Software Interface Standard). CMSIS addresses the issues of portable macro defines and intrinsic functions common to the Cortex-M CPU cores. As each MCU has its own set of I/O peripherals, silicon vendors provide header files and sometimes C source files which let a user access the peripheral I/O registers and functions.
Hello, in 2018 we saw some exciting developments at ImageCraft. To celebrate, we are offering 18% off until end of the year. Use coupon code BYE2018 when you check out. Follow the instructions here: https://imagecraft.com/buy/how-to-use-coupon-code
Happy Thanksgiving! The first public release of REXIS is now available, as part of V9.07.00 of JumpStart C++ for Cortex, which you can download by clicking on the link.
ImageCraft creates different REXIS editions to fulfill the different needs of embedded developers. For consulting engineers, you can prototype, test, and work with the REXIS binary release by installing the JumpStart C++ for Cortex compiler. Get a ST-Nucleo F411RE and you can start running the examples immediately. The binary release is free to use for non-commercial use.
If you have read the blog on REXIS Examples, or the REXIS documentation, you may have noticed that REXIS supports synchronous message passing API, in addition to the more common asynchronous messaging with mailboxes. Synchronous message passing is not a new idea. Indeed, the inspiration came from QNX Neutrino, the message passing kernel that powered the BlackBerry smartphone devices in the early 2000s.
Synchronous message passing is a great idea. For example, it makes writing a “full-blown” OS (e.g. Linux) based on microkernel simpler. In such a system, OS services such as the file system support, networking etc. are written as regular tasks or processes instead of being part of the kernel code. Of course having a full OS is less important in a microcontroller system, but nevertheless, the use of synchronous message passing can give firmware a cleaner design. (We will see another example in this post below.) As a footnote, REXIS’ functions can be said to reflect those of a microkernel, perhaps pointing to a possible future path for its development.
Some RTOS producers are loathe to benchmark their products, or allow their users to do so. Here at ImageCraft, we welcome it :-). So let’s dive in and look at some numbers for the REXIS message passing API calls.
Even though we released the AVR and the Cortex-M debuggers a number of years ago, apparently some of our users do not know about it. JDB debugger is fully integrated with the CodeBlocks IDE, and contains a number of easy to use features such as I/O register view. The normal list price is $150, but for a limited time only, if you already have a compiler license, you can purchase the debugger for just $100.
As we are finalizing the initial release of REXIS, we would like to provide some quantitative data on some of its features so that users and potential users can make intelligent decisions regarding this product.
There are a variety of methods for measuring timing on MCU firmware. Two popular methods are 1) using an internal MCU timer, and 2) toggling a GPIO pin so that you can observe the output waveform with an external device.
REXIS is both ImageCraft’s RTOS and a component of the JumpStart IoT Connectivity Suite. It’s powerful yet easy to use. This post is from an excerpt of the forthcoming REXIS User Guide, containing examples to demonstrate REXIS features.
As some users may not be familiar with using an RTOS, let’s dive in and look at some examples. The examples are located in <install root>\rexis\examples\, and introduce all the major features of REXIS. (This document will not provide the full listing of the programs, as minor details may change.)
The development world is full of IDE, and “everyone” uses GCC anyway. So how can ImageCraft be better? One way we can achieve excellency is by making tedious or complex things easy to do.
For example, there are different floating point options for the Cortex-M MCUs, depending on what architectural features the CPU core support. For example, Cortex M0 and M3 cores must use software floating point libraries whereas M4 has optional single precision floating point FPU, and the M7 has optional single and double precision FPU.
But wait! There’s more: by default, the printf function in the newlib/nano-lib does not support printing of floating point values (to reduce the size of the function) and…, and…, … These are not hard to figure out, just tedious to remember the exact options to use for each one.
So of course we are adding new options to the Project Build options in the next release of the JumpStart C++ for Cortex IDE:
Simple, easy to use. That’s our motto.
Oh, one more thing. What’s that QFPlib option? Stay tuned and find out…