You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• VDC Survey Results
• Working With the Cortex-M MPU
• Brooks on Comments
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm for more details.

"When executives or clients demand unrealistic and unobtainable project schedules, the probability of substantial cost overruns and schedule delays will double; the actual project's schedule will probably be twice the optimistic schedule demanded by the stakeholder." Gack's Law.

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Trenton Henry sent a number of suggestions:

A lot of people express frustration with vendor's libraries and tools. Andy Nevill of Cypress sent some CY8CKIT-044 PSoC 4 M-Series Pioneer Kits (Cortex M3 based dev kit with Bluetooth LE, Capsense, Programmable Digital (CPLD) and programmable analog) for the giveaway. He feels these address the issues Jon Titus identified. So, at the end of February, 2017 we'll award these to two lucky contest winners.

Enter via this link.

VDC has just released a new survey of the embedded space; many Muse readers sent them data. They have generously agreed to share the results with the community (generally one only gets a small subset of the data; it appears to me they are sharing it all).

Selected highlights:

• 54% of embedded projects include a GUI.
• 32% are battery-powered.
• 49% have some sort of wireless connectivity.
• 35% have security enhancements.
• Projects are small - the mean number of engineers involved is 19, but the median is only 7. Development costs average $27 million, but the median is only $250K. The average project consists of 627,000 lines of code, though the median is 20,000.
• It's a Cortex-M world - 30% of projects use at least one.
• 65% of developers run their tools on some version of Windows, about 30% on Linux, and practically no one on Macs. Respondents expect that to change little in the next three years.
• Only 22% report using a "static analysis/code checker" tool. Alas, the survey lumped Lint and very different tools like those from Coverity et al into this bin. These are very different animals, both in what they do and pricing.

The use of a hardware Memory Management Unit (MMU) is a powerful way to assure system reliability. Alas, till recently most MCUs didn't have an MMU. Now, though, some ARM Cortex-M devices include a Memory Protection Unit (MPU), which is scaled-down MMU. Correspondents have complained that ARM's literature about the MPU is confusing. I agree.

Ralph Moore of Micro Digital graciously agreed to write a multi-part series for the Muse about using the MPU. Full disclosure: his company has taken an ad in the Muse this week.

Here's part 1:

Introduction

Embedded systems are being drawn more into the IoT and thus, security in the form of protection of critical system resources is becoming increasingly important. Most security mechanisms, for example, depend upon secret keys and most embedded systems have mission-critical software, both of which must not be compromised. Effective protection can only be achieved via hardware means.

The Cortex-M Memory Protection Unit (MPU) is difficult to use, but it is the main means of hardware memory protection available for Cortex-M processors. These processors are in widespread use in small- to medium-size embedded systems. Hence, it behooves us to learn to use the Cortex-M MPU effectively in order to achieve the reliability, security, and safety that modern embedded systems require.

MPU Basics

Cortex-M processors have three modes of operation:

• Handler Mode: privileged mode for ISRs, fault handlers, the SVC Handler, and the PendSV Handler. This mode can be entered only via an exception.
• Privileged Thread Mode: privileged tasks (ptasks) run in this mode. It can be entered only from handler mode.
• Unprivileged Thread Mode: unprivileged tasks (utasks) run in this mode. It can be entered from either of the above two modes.

In the discussions that follow, the first two modes are collectively called pmode and the third mode is called umode. Similarly, I refer to pcode, ucode, pSSRs, uSSRs, etc. These are not industry-standard terms, but rather are introduced here to simplify discussions.

Cortex-M0/1/3/4/7 MPUs have 8 slots. Each active slot defines a memory region with its own attributes such as size, alignment, read/write (RW), read only (RO), execute never (XN), etc. Slots in which the EN bit is 0 are inactive and have no effect upon memory accesses. Hence a user is not forced to use all slots. Unused slots are usually filled with 0's to disable them.

Two unfortunate aspects of the Cortex-M MPU are that memory region sizes must be powers of 2, ranging from 32 bytes to 4 GB and memory regions must start on multiples of their sizes. These requirements undermine the utility of the MPU by making it difficult to use without wasting substantial memory. This and uncertainty about how to define MPU regions have, I think, been major impediments to better usage of MPUs in embedded systems.

How to define MPU regions is the subject of this blog. We'll deal with wasted memory in a future blog. Where necessary for specificity, examples assume the SMX® RTOS and the IAR EWARM tool suite. However, the techniques presented are applicable to all RTOSs and tool suites with similar capabilities.

Defining Sections

The process starts with defining sections in the code. In the following discussion, .taskA_code and .taskA_data are the code and data sections reserved for taskA. .taskA_code contains the main task function and any subroutines that are specific to it. .taskA_data contains static variables used by taskA, if any.

Start by defining sections in the C source code modules. For example, in each C module containing code for the .taskA_code region, start the code with:

  #pragma  default_function_attributes = @ ".taskA_code"
  /*  Place taskA functions here. */
  #pragma  default_function_attributes =       

where .taskA_code is a name to identify the section. Several functions can be enclosed above. Also, the above structure can be repeated in other modules and all taskA functions will be combined into a single .taskA_code section.

For data:

  #pragma default_variable_attributes = @ ".taskA_data"
  /* Place taskA data here. */
  #pragma default_variable_attributes =

As with code, many variables can be enclosed above and the above structure can be repeated in other modules to create a single .taskA_data section containing all of the static variables, specific to taskA.

Creating and Locating Linker Blocks

The linker plays a prominent role in assigning the sections defined in the C code to actual memory locations. For example, in the linker command file (.icf extension for ILINK) for the .taskA_code section:

  define region ROM  =  mem:[from 0x00200000 to 0x002FFFFF];
  ...
  define block taskA_code with size = 1024, 
         alignment = 1024 {ro  section .taskA_code};
  ...
  place in ROM {block taskA_code };

Note that alignment equals the size as required by the MPU. Also note that the section and block names differ by only a ".". This is not a requirement, but it is convenient.

Memory Protection Array (MPA)Template

Now, in a C file or header file, define:

  #pragma section="taskA_code"
        

Redefining the linker block as a compiler section is an EWARM idiosyncrasy that I don't understand, but it works.
Finally, we define the template for the MPA of taskA:

  const MPA mpa_tmplt_taskA = 
   {
   /*0*/ {RA("ucom_data")  | V | S0, RW_DATA | RSI("ucom_data")  | EN},
   /*1*/ {RA("ucom_code")  | V | S1,  UCODE  | RSI("ucom_code")  | EN},
   /*2*/ {RA("taskA_data") | V | S2, RW_DATA | RSI("taskA_data") | EN},
   /*3*/ {RA("taskA_code") | V | S3,  UCODE  | RSI("taskA_code") | EN},
   /*4*/ {/* taskA_stack */  V | S4, RW_DATA}
   };

The macros used above are defined as follows:

   /* region s address */   
   #define RA("s") ((u32)__section_begin("s"))
   /* region s size index */
   #define RSI("s") (30 - __CLZ(__section_size("s")) << 1)

In the above template two common regions have been introduced for subroutines and static data common to taskA and other tasks. Also, a region is reserved for the taskA stack. The use of the template and MPA will be discussed in my next blog, "MPU Multitasking".

For more information, see www.smxrtos.com/mpu.
Ralph Moore, ralph@smxrtos.com

Dave Brobst had a final say on comments:

Let me know if you’re hiring embedded engineers. No recruiters please, and I reserve the right to edit ads to fit the format and intent of this newsletter. Please keep it to 100 words. There is no charge for a job ad.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

Yet another about that ancient Pentium division bug:

Q: According to Intel, the Pentium conforms to the IEEE standards 754 and 854 for floating point arithmetic. If you fly in aircraft designed using a Pentium, what is the correct pronunciation of "IEEE"?

A: Aaaaaaaiiiiiiiiieeeeeeeeeeeee!

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster.