Why embedded developers need to understand Special Function Registers (SFRs)

Posted by Magnus Unemyr on Jul 25, 2016 10:36:45 AM

What is the difference between PC/web developers and embedded developers? Both categories have their unique challenges. But - I would argue (and I am sure someone will react strongly to this) that embedded developers need to have a much more detailed knowledge than developers targeting PC's. PC and web developers on the other hand, often have other concerns - like user load scalability.

Coming from a PC development background into the embedded space about 25 years ago, I had to face "strange" concepts like bootloaders, interrupt vector tables and interrupt handlers, linker configuration files, special function registers, flash programming, and a whole set of offer magic stuff I had never heard about during my earlier years as a PC developer.

Not to mention it wasn't possible to debug the system in a way that was nearly as convenient as it was on a PC (at the time, Borland had just introduced a debugger in its Turbo Pascal IDE, providing a modern debugger experience at an affordable price for "the masses" for the first time).

One of the key concepts any embedded developer needs to grasp, is the Special Function Registers (SFR's) mentioned above. What are they, how do you use them, and why do every embedded developer need to master them perfectly?


A special function register is just a memory location with a special meaning to the CPU. As such, a special function register can be defined (by the CPU designer) to be on hardcoded address, say 0x0000FF34. A special function register can be any size the CPU designer so chooses, but are often 8/16/32 bits.

By writing one or more bits into an SFR, you configure the CPU to do something, or make it start or stop some functionality. By reading one or more bits in an SFR, you can query the status of some functionality in the CPU.

This essentially gives us 3 different uses for SFR registers, and/or SFR register bitfields:

  • Configure some H/W functionality (such as setting the baudrate of a UART channel)
  • Control some H/W functionality (such as sending a byte on a UART channel)
  • Query the status of some H/W functionality (such as checking if a byte has arrived on a UART channel)

In short, you use SFR's to configure, control and query the hardware functionalities in the microcontroller device, especially its peripheral modules. Common hardware functionalities that needs use of SFR's are:

  • UART, USB, Ethernet
  • LCD and touch controllers
  • Timers
  • DMA, MMU
  • Flash programming
  • Etc

What SFR's a particular microcontroller device (like STM32, LPC, Kinetis etc) have, are defined by the hardware device itself (or rather, its chip designer). You will need to read your chip manual to determine what SFR's it has, and what meaning the individual bits and bitfields have.

Often, chip vendors nowadays abstract away much of the need for direct access to the SFR's, thanks to hardware abstraction software libraries (i.e. device driver libraries). This means embedded developers can use the device driver API that comes with the software libraries to access and control hardware features like UARTs or Timers.

However, any software developer worth his or her salt reads the chip manual and education himself or herself on what hardware capabilities there are to exploit, what peculiarities they may have, and how they work. Often the device driver libraries only provide an API for a subset of all the capabilities offered by the H/W as well.

In many cases, your embedded design doesn't work as intended at first, and you need to debug it. Perhaps a Timer interrupt doesn't fire as expected, or the UART doesn't send characters as intended. Looking into the bits of relevant SFR's are a great way to debug this type of problems, and are often necessary. To that end, modern embedded IDE's, like Atollic TrueSTUDIO, include an SFR viewer that visualize all SFR's and their bitfield values in the selected muicrocontroller device.Make sure to use it, and read the CPU manual, to understand what is really going on in the CPU.

What are your experiences in developing and debugging embedded systems, in relation to SFR registers? Feel free to leave a comment below!

Topics: Debugging