Here’s an interesting embedded software development bug I ended up dealing with, relating to mutual exclusion implementation on ARMv6 and later CPU cores. The project involved yet another board based on an i.MX6Q (Which contains four ARM Cortex-A9 CPUs), running QNX with SMP.

....

Recently at work, someone said “Ed, can you add a password for ssh access to this embedded board which is running QNX?”. Shouldn’t take long I thought, being basically just an admin task. It then did take quite a chunk of the day, with my ssh client in Ubuntu stubbornly refusing to allow me to log in to the board. Here is one reason why it doesn’t work.

....

So you’ve written a Qt application, and naturally, you want people to use it. Well then you’d better prepare a build of it for Windows if you haven’t already, because like it or not, that’s what most of your likely users are going to be running (Unless its an OS specific tool).

Surprisingly, the Qt project doesn’t provide any redistributable library packages specifically for the purpose of providing alongside a built application. The obvious method of copying DLLs from a Windows Qt installation can create a rather large footprint. The best course is to build a set of static Qt libraries optimised for size, and without dependencies on those huge ICU DLLs. So here I present to you the simplest “recipe” for distributing your Qt Windows application in a trim manner.

....

Freescale’s i.MX6 chips have rather comprehensive secure booting capabilities. When enabled, the High Assurance Boot (HAB) framework in the chip allows only signed binaries to be loaded by the on-chip boot ROM. The code signing is based on assymetric cryptographic keys, the public keys are burnt into OTP registers on the chip. Here I describe how I got the process of enabling i.MX6 secure boot wrong, then after despairing that the customer’s shiny new £400 SabreSD board was now unbootable, managed to recover it with JTAG.

....

While writing Backupdoit I needed to access data from the doit.im server. At the time of writing this, doit.im doesn’t appear to provide any documentation on their web API or encourage 3rd party usage. Therefore in order to see the data as it is downloaded from the doit.im site, so I could fetch and process that same data in my application, I had to snoop the HTTP traffic.

Being an embedded developer in my day job, dealing with RESTful web APIs and all that good stuff is a bit off-track for me. However, given that embedded devices are only going to get more connected to the web/cloud/IOT/whatever it’s called this week, here are a few pointers on how I did it for anyone in a similar position.

....

Here’s a quick tip on a problem I ran into recently, when I decided to debug a VOIP stack on a PowerPC box with GDB from my x86 dev PC. I found a few people on the TI E2E forum struggling with the same issue, the solution was not immediately forthcoming on Google, but was found after a quick glance at the GDB reference card.

Say you want to debug a dynamically linked executable with GDB, which is cross compiled and running on a remote target using gdbserver, you could get errors related to the loading of the shared object libraries when the program is set running. Here is the output with such errors that I got during my debug session:

....

Here is a tutorial on how to set up your QNX image to make it work with Qt Creator, then some explanation on configuring Qt Creator itself for QNX with Qt 5.

The microkernel based RTOS, QNX, has remote debugging on the target pretty much nailed down out of the box. Various plugins in the Eclipse based Momentics IDE, included as part of the QNX development suite, provide one click download and debugging, as well as all sorts of application and system level profiling and analysis. So why would anyone need to use Qt Creator to debug with QNX?

....