"Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 425, July 5, 2021
Copyright 2021 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

Contents
Editor's Notes

SEGGER Embedded Studio cross platform IDE

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

I'm off sailing this month so may be very slow in replying to email.

Quotes and Thoughts

When it comes to software quality, you can pay me now or you can pay me a lot more later. Karl Wiegers

Tools and Tips

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

Chris Svec sent this:

Elecia White, embedded consultant, podcast host, and author of "Making Embedded Systems," has a publicly available talk about understanding map files. The talk is called "Buried Treasure and Map Files" and here's the link:

https://www.youtube.com/watch?v=XRXLUcbJIxY

Here's her blurb:

Often overlooked, the map file can provide a wealth of information to the intrepid developer. Map files can help with optimizing for RAM usage and/or code space, updating firmware (with or without a bootloader), debugging difficult crash bugs, and statistical profiling.

With so much information, how can you use it? Where do you look? How do you turn the wall of text and numbers into a true map of the code? Elecia will demonstrate how to use map files. She will focus on an ARM Cortex-M but it will be relevant to other processors. Slides, files, and link to The Map files can be found at: https://embedded.fm/blog/mapfiles

It's a great talk about understanding what map files are and how you can use them to understand your code and embedded system.

Beware the Brown-Out Reset Circuit!

Low-power MCUs usually have a built-in brown-out reset (BOR) circuit. Unfortunately, most are poorly designed and/or lightly documented and should not be used.

One popular ultra-low power MCU, from a vendor who noisily advertises two to three decades of coin cell operation, has a BOR which is off by default. On, it requires somewhere between 8 (typical) and 16 uA (worst case). If your system is running from a battery, for a decade of life from a CR2032 the system's average power draw cannot exceed 2.5 uA. Even if one were to foolishly use the typical number, the BOR by itself will deplete the battery in just a couple of years.

Another vendor, pushing extremely-low power ARM parts, rates the BOR at 0.49 to 1.26 uA -- typical. There's no max listed; there's not the slightest guidance of what statistical distribution one can expect when making thousands of systems. 1.26 uA eats half the 2.5 uA budget.

In another case the datasheet reads about the BOR: "In the deeper sleep modes, this will contribute significantly to the total current consumption."

As Deming said: "In God we trust, all others bring data." They didn't, and it strikes me as risky to rely on divine intervention instead of careful analysis. I'd be wary of using these uncharacterized parts in long-lived applications. As always, read the datasheets pessimistically and carefully.

When does the BOR interrupt occur? In some cases the voltage range is very wide; an example is an MCU where it is listed as 2.05 (min), 2.2 (typ), and 2.35 volts (max). Doing worst-case design you'd have to assume that the BOR may occur at 2.35 volts.

The following graph shows the voltage a CR2032 battery can deliver as it discharges as a function of load (note the 0.5, 10 and 30 mA lines):

Brown out reset curve

The 10 mA load line is pretty common for an awake MCU with enabled peripherals; 30 mA is not unexpected if there's any sort of wireless comm going on. The heavy red line is at 2.35 volts, the max value where we may see a BOR interrupt. Note that in this case the BOR circuit will signal a dead battery, if there's a 30 mA load, shortly after you ship the product. With a 10 mA load the battery-dead indication happens when there's still 31% capacity left.

In other words, the BOR circuit is useless in this sort of battery-operated scenario.

A much better alternative is to leave the BOR off and use the ADC. Wake up from time to time, apply a load similar to what the system normally needs when awake, and read Vcc. If it's near 2.0, then signal a battery failure (or take whatever action your system needs in this situation).

If such a reading is taken once every ten hours (surely, more often than needed), and 10 mA were pulled for 1 ms during this reading, over a decade this eats only 0.03 mAh, or 0.01% of a CR2032's capacity. And, by manually reading the ADC a more nuanced approach to battery management is possible than by relying on a single, poorly-controlled, BOR voltage.

Working With Your Hands

When I was about 8 or 9 my grandfather would bring loads of old lumber by the house for me. I built a succession of "forts" in the backyard, tearing each down as soon as it was completed in order to craft a more perfect version.

About the same time my very frugal dad bought a new Sears Craftsman drill. Old timers will remember these: aluminum cased, they ran forever. He gave me his old one, which I used for many years till it was lost in a shipwreck. That drill spawned many creations, in the early days most silly and non-functional.

Building stuff with scraps led to making radios, and then other bits of electronics, till in high school my dad and I companionably built a separate room in the basement for my electronics lab. In those days WWII surplus equipment was plentiful and cheap. Working with vacuum tubes eventually morphed into transistors and ICs.

I went to college to study EE thinking that it was electronics that was so fascinating, but over the years have realized that, while the subject is utterly compelling, what drove me into engineering was the love of making things. Wiring up a circuit. Designing that circuit. Creating software that does something. (And this is probably why I'm drawn to embedded: PC programmers write code that doesn't do anything fun; embedded people flash lights and drive motors.)

So today, 60 years after banging nails and wood into forts, I have a pretty complete woodworking shop. It's still fun and rewarding to take an idea and mold it into reality. With my own hands. Those forts morphed into building a barn (I'd long dreamed of building a real structure; turns out, never again!).

While many engineers never build things, what drove me into the field was the connection between the intellectual work of solving a problem on paper and then converting it into reality. In truth, most of the systems I designed were built by technicians, but making them work meant surrounding myself with test equipment and tools. Doing stuff. With my hands. C code typed with clean fingernails ultimately makes things happen!

My stepson got a degree in business management and worked for many years in an office, analyzing data and writing reports. Now he's working on boats. He has found that, for him, working with his hands is more satisfying than white collar work.

(For a different - and fun - take on programming as drudgery, listen to Stan Roger's White Collar Holler.)

I have known incredibly erudite engineers who have never touched a soldering iron yet are responsible for amazing creations. Others were the opposite. One RF engineer didn't do schematics till he had a working prototype; his soldering iron rendered a 3D circuit that, once working, was committed to paper. Steve Ciarcia of Byte and Circuit Cellar fame often said his favorite programming language was a soldering iron. We come at this field from many directions and we need both the lofty intellectual as well as the inveterate tinkerer.

As Charlton Heston said, "You can pry my oscilloscope from my cold, dead hands."

Why did you become an engineer? What is your story? Do you have any regrets?

More on Testing RAM

Jonathan Morton had some comments about testing RAM on the fly from the last issue:

The correct way to do ECC, IMHO, is to have the correction circuit automatically write the correction back to RAM.  A scrubber then only needs to read over the RAM, and let the correction circuit do its thing automatically.  This arrangement avoids a lot of awkward race conditions.  If the correction circuit can insert wait-states while it does its work, that may also lead to a significant reduction in logic complexity, at a performance cost that is only incurred on those exceptionally rare occasions that an error is detected.

ECC is also a great way to detect hard errors.  You're looking for bit errors that occur frequently on the same RAM cell (so have the correction circuit log the error and pick it up in a background task for analysis), or which persist after being corrected.  If you have a memory mapping unit, you can then easily remove the affected page from use without any substantial interruption of service, by copying the contents to an error-free page.  Obviously this doesn't cover dysfunctions of the address bus, so a static test at boot time may still be warranted.

Caches on some CPUs are also ECC or parity protected.  ECC on write-back caches, parity on write-through and instruction caches (where a parity mismatch is cured by an invalidation and re-fetch).  A parity check can be considerably less expensive than ECC protection, since it only requires one bit per machine word or even cacheline, rather than per byte, and the check hardware is just a wide XOR gate.  This also applies to use of parity checks on RAM, for applications where instead of correcting the error, a reboot can be tolerated.

Failure of the Week

From Jim Allyn. He says "But it's a dry heat, and honestly, it didn't feel a degree over 1000".

Failure of the week

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Jobs!

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.




Joke For The Week

These jokes are archived here.

A programming language is low level when its programs require attention to the irrelevant.

About The Embedded Muse

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. can take now to improve firmware quality and decrease development time.