Go here to sign up for The Embedded Muse.
The Embedded Muse Logo The Embedded Muse
Issue Number 463, February 6, 2023
Copyright 2023 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.

Editor's Notes


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.

Quotes and Thoughts

For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. Richard Feynman

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.

Mark Peterson sent a link to the old GE SCR Manual, and to a zillion other old publications.

John Hartman also sent a link to many old pubs.

Tim Kreyche noted that Windows does support some audio goodies:

John Carter wrote: Alas, now most devices have _much_ more capable audio, but lack a simple direct synchronous "beep" api. Now the only audio hint is that the cooler fans sound as if the machine is trying to take off.... very crude and low resolution.

Windows does have a simple .NET library API for playing a beep through a motherboard attached speaker. It’s either Beep() or Beep(frequency, duration). No sound card needed. There are other simple APIs for beeping via a sound card.

Tired of cookies? I happen to like them a lot, especially chocolate chip. But for keeping them off your computer, Roy Tellason wrote:

,  I use a browser plugin called "cookie autodelete" and watch them go away.  It's astonishing to me how a brief visit to some site can result in several hundred cookies being dumped on my machine.  When a site prompts me with a popup to accept cookies rather than go along with that I use "nuke anything" to get rid of the popup.  Sometimes they send 'em anyway,  sometimes they don't.

Larry Marks passed along this link to a webinar titled "Creating Bug-Free Software", which will promote Rust, Ada/SPARK, and analysis tools as a way to generate high-quality code.

Freebies and Discounts

A ShortSniffer! This unit will find short circuits. There's more on it later in this Muse.

Enter via this link.

Bugseng has a static analysis tool that sounds interesting. They are willing to do a free static analysis of up to five open-source projects. Read more about it here.

On RAM Tests

This email arrived in January:

Dear Jack,

For our [product name deleted] I implemented the classic aa/55 RAM test. A colleague called me a moron for doing this, but won't elaborate. What's wrong with my test? We didn't study this in college (I graduated last year).


[Name withheld]

Well, implementing a substandard algorithm does not make the writer a moron! I'd place not a little of the blame on his arrogant colleague who missed an opportunity to be a mentor.

It is true, though, that this test just does not work - yet this algorithm, or one like it, is still very common.

The classic test is "walking ones", which guarantees correct operation no matter how the memory may have failed. It's pretty easy to implement but is so slow it's often impractical. No one wants a multi-minute wait for a system to power on.

Alas, some developers create speedy tests that are ineffective. The most common is to write a pattern of alternating ones to all of memory, verify the writes work, and then repeat the test with the ones complement. In pseudo-code:

Loop through memory:
   write 0xaaaa to each location
Loop through memory:
   read memory and test that each location is 0xaaaa
Loop through memory:
   write 0x5555 to each location
Loop through memory:
   Read memory and test that each location is 0x5555

This test will return a "memory is OK" flag even if the address bus has a problem. Suppose all of the address wires to the RAM array are grounded; the test will write and read to a single location and will "pass."

In some cases it will pass if there's no RAM. Depending on the bus structure, the capacitance of the wires can hold the 0xaaaa/0x5555 on the data bus returning the write data back to the read cycles.

There are many alternative ways to ensure RAM is functioning properly. I've written about this extensively here. Some of those approaches are very effective and even faster than the bogus 0xaaaa/0x5555 algorithm.

But when it comes to any sort of diagnostics, it is important to clearly define your goals. Why run the test? What will the result be? Who will be the unlucky recipient of the bad news in the event an error is found, and what do you expect that person to do?

Will a RAM problem kill someone? If so, a very comprehensive test, run regularly, is mandatory.

Is such a failure merely a nuisance? For instance, if it keeps a cell phone from booting, if there's nothing the customer can do about the failure anyway, then perhaps there's no reason for doing a test. As a consumer I couldn't care less why the phone stopped working. if it's dead I'll take it in for repair or replacement.

Is production test - or even engineering test - the real motivation for writing diagnostic code? If so, then define exactly what problems you're looking for and write code that will find those sorts of troubles.

Remember that today's hardware is often very highly integrated. In the case of a microcontroller with on-board RAM the chances of a memory failure that doesn't also kill the CPU is small. Again, if the system is a critical life support application it may indeed make sense to run a test as even a minuscule probability of a fault may spell disaster. But many other systems will not benefit from this test.

Do note that C code needs RAM to run. In general the tests will produce useful results only if done in the assembly startup code, before any returns or pops execute.

Binary Editing

Need to examine or edit your binary? Andrzej Telszewski sent this:

Is your binary what you think it is?

There is a [LIEF project](https://lief-project.github.io/) that allows one to work with executable files using Python.

I recently used it in a commercial product to add a CRC to the firmware file. I added the CRC section directly to the ELF file, so that any derived file (BIN, HEX) would match the ELF 1:1.
(The other option would be to append the CRC value directly to the BIN or HEX files, but then they would not match ELF 1:1.)

To obtain BIN or HEX file one normally runs `objcopy` on the ELF file, and that was what I did. I also wanted `objcopy` to fill the gaps between sections with 0xFF, which it can do.

What I did not expect is that, after running `objcopy`, the HEX file didn't match what was in the ELF file. There were literally too many issues to describe them all in the short format of TEM.

But what I learned is that the GNU `ld` linker language has the `ASSERT()` command. I started using it to ensure my assumptions are fulfilled, and surely, it quickly proved me some were not.

Coming back to LIEF (and `intelhex` module available in Python package index -- `pip`.)

I implemented a unit test that computes the CRC from HEX file records and compares it to the value found in the CRC section in the ELF file. It took some linker script tweaking to make them match.

I also implemented a unit test to ensure that the sizes of the binary as found in the ELF and HEX files and in the metadata structure in the ELF file -- that they all match.

Finally, just to mention, the size was computed from and inserted into the ELF file using LIEF.
Really helpful tool this LIEF project. :-)

We take for granted that the firmware file (BIN or HEX) for the programmer is correct. I learned that it might not be always the case and so wanted to spread the word. :-)

The ShortSniffer

Need to sniff your shorts?

Perhaps I should rephrase that.

Given that you know there's a short circuit on a PCB, how do you find it? Especially if it's on wires with lots of nodes, like a bus.

Enter the ShortSniffer, a very clever, and fun, tool that injects a small audio signal into the shorted connection. You move a sensitive probe over the board and listen to an audio signal in headphones. There's a picture in the "Freebies and Discounts" section above, as the vendor sent us one to give away this month.

The cool thing is that the audio is in stereo. As the probe moves around the board the sound moves between your ears, guiding you in which direction to move the probe. The tag line is "Follow the sound to the short."

The maker claims it can locate a short, even buried in a multi-layer board, to within one mm. Drill a hole and break the connection.

Multiple probes are supported depending on the sensitivity required.

The ShortSniffer web site includes lots of examples, videos showing the device in action. Here's one. Listen to the audio with your headphones on and you'll get the full experience using an audio signal moving between the left and right channels to find the short. It's a pretty cool video.

Prices range from $290 to $380. Definitely worth checking out.

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.

Eric Haag found this nifty regulator that might run for a microsecond from a small battery:

From a (very fit!) Ben Vespone:


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.

Captchas are getting harder!

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.