embedded software boot camp

Freescale customer service

March 10th, 2015 by Nigel Jones

I have to admit to having a soft spot for Freescale microprocessors. The first micro I ever used was a Motorola 6809 and for the first few years of my career I worked exclusively on 6800’s, 68HC11’s and 68000 processors.  Times changed and I largely moved away from the product range, although I did return periodically as projects dictated. Well such a project has recently come up. The project requires me to make some modifications to an existing code base and as is often the case, the original compiler and its license file have been lost to the winds of time. Accordingly, I downloaded an evaluation copy from Freescale’s web site and got to work.  After convincing myself that there were no significant issues with moving to the latest compiler version, it was time to purchase a license. And as the joke goes, that’s when the trouble started…

Freescale offers various versions of the compiler, and in addition offers various optional software components that can be purchased. Trying to work out which components I needed to purchase was incredibly hard. Anyway, after considerable time, I came up with what I thought was needed and had my client purchase the requisite licenses. Downloading and installing the licenses was ridiculously complicated (as in it took about an hour to wade through all the documents), but I eventually got there. I then invoked CodeWarrior and got a wonderfully obtuse licensing error message that seemed to be saying I needed to purchase an additional component. However the component wasn’t for sale on Freescale’s website…

Accordingly I called customer support. Here’s the gist of the conversation:

Freescale: This is is unusual. It shouldn’t do that.

Me: OK.

Freescale: We don’t offer support for licensing issues over the phone. You’ll have to send an email to technical support detailing the problem.

Me: OK. How long is the response time?

Freescale: 48 – 72 hours.

Me: Do I have this right. Your product that I’ve paid for doesn’t work as advertised, you don’t offer telephone support for licensing issues, you require me to send you an email and it will then take you up to 72 hours to get me an answer?

Freescale: Yes.

I’m not sure what planet Freescale resides on, but this level of service simply doesn’t comport with what’s needed in the embedded space today. I think I understand now why I see so few Freescale designs. Is my experience unusual or is this the norm for Freescale today?

Firmalware

February 17th, 2015 by Nigel Jones

There’s a fascinating story from Reuters (with a far more detailed report from Kaspersky) about how a very sophisticated hacking operation, presumably the NSA, has been targeting computers by reflashing the firmware of hard drives such that the attacker controls what is loaded at boot time. If you think this has shades of Stuxnet about it, then you aren’t alone.

Why am I posting this? Well I think in the embedded community there’s been a certain amount of nonchalance concerning malware attacks on firmware, aka Firmalware. I see a lot of shrugs – it’s firmware, so it’s not modifiable, or who wants to take control of X, or to attack it they will need the source code and so on. Well if you read the articles – and I strongly recommend you do, then you’ll read that the attacker almost certainly did get hold of the source code for the disk drives, that they exploited undocumented commands, that they reprogrammed the disk drive firmware and that they proceeded to take complete control of the victim’s computer.

So what’s this to do with you? Well I strongly urge you to consider the consequences of what would happen if an attacker took control of the gadget you are working on. For example, sitting on my desk right now is a USB dongle used to receive over the air digital TV broadcasts. It doesn’t sound like it’s a great avenue for exploitation. However, an attacker could easily do the following if they had control of this device.

  1. On broadcast (i.e. over the air) command, switch the dongle into acting like a USB drive. USB drives are a major source of malware infection.
  2. Again on broadcast command, force the dongle to tune to a specific frequency resulting in the user being exposed to whatever the attacker wishes them to.

Although I’m not exactly the paranoid type, it really doesn’t take much imagination to work out how legions of embedded devices could be made to do some rather nasty things to their users.

The bottom line. If you haven’t thought about what happens if an attacker gets control of your gadget then you aren’t doing your job. Some things to ponder:

  1. How secure is your source code?
  2. If you have a bootstrap loader, how secure is it?
  3. When you distribute new firmware for installation on your gadget, is it distributed in encrypted form?
  4. Even if it’s distributed in encrypted form, is it downloaded in encrypted form?
  5. How do you protect the encryption keys?
  6. Are you setting the lock bits correctly so as to at least make binary extraction more challenging. (However don’t get too cocky – see this site )

The list could go on – but I think you get the idea.

Shifting Styles

November 27th, 2014 by Nigel Jones

To say it’s been some time since I last posted is an understatement! I won’t bore you with the details other than to note that sometimes there just aren’t enough hours in a day.

Anyway, today’s post is about a stylistic issue I’ve noticed in just about all code I’ve ever looked at. Unless you are a closeted BASIC programmer, you probably don’t ever write something like this:

foo = foo + 6;

While there’s nothing particularly wrong with this, other than looking rather odd from a mathematical perspective, just about every C programmer would use the += operator, i.e.

foo += 6;

Indeed this is true for all the arithmetic and logical operators. I.e.

foo *= 6;
foo /= 6;
foo -= 6;
foo ^= 6;
foo |= 6;
foo &= 6;

However, when it comes to the shift operators, something odd seems to happen. Almost no one writes:

foo >>= 6;

or even rarer:

foo <<= 6;

Instead folks resort to the syntax of BASIC and use:

foo = foo >> 6;
foo = foo << 6;

Why exactly is this? This thought was triggered by me looking at some of my own code from about ten years ago. Sure enough right in the middle of what was an otherwise well written piece of code (in the sense that ten years later it was easily followed and was a breeze to adapt to my latest project) I found a:

foo = foo << 6;

I have no real explanation other than we are all creatures of habit and sometimes get into inconsistent programming styles. While I wouldn’t fault someone for doing this, I do think that if you quite happily use += but not >>= then you should ponder your rationale for being inconsistent. Perhaps it will trigger a bigger introspection?

 

The engineering – marketing divide

April 6th, 2014 by Nigel Jones

We have all sat in surreal meetings with the sales and marketing folks. This video captures the dynamic perfectly (caution – you won’t know whether to laugh or cry):

The Expert Video

I actually have some sympathy for the marketing people portrayed here, as it must be very hard when you’re so far out of your depth. The person I can’t stand is the smarmy sales guy who’ll promise anything to make a sale, regardless of the consequences. I have to admit to having chewed out a few sales guys in my time that have pulled stunts like this one.

Anyway, I don’t have any particular insights on this other than to let you all know that you’re not alone when it comes to meetings like these.

Replacing nested switches with multi-dimensional arrays of pointers to functions

March 17th, 2014 by Nigel Jones

It’s been way too long since I’ve written a blog post. To those kind souls that have written to inquire if I’m still alive and kicking – thank you.  The bottom line is that there simply aren’t enough hours in the day. Anyway in an effort to get back in the groove so to speak, I thought I’d answer an email from Francois Alibert who wrote to ask how to replace a nested switch statement with a multi-dimensional array of pointers to functions. Here’s a program that illustrates his conundrum:

#include <stdint.h>
#include <stdio.h>

typedef enum 
{State1, State2, State3, Last_State}
MainState_t;

typedef enum 
    {SubState1, SubState2, SubState3, SubState4, SubState5, SubState6, Last_SubState}
SubState_t;

void demo(MainState_t State,  SubState_t SubState);

/*     Functions called from nested switch statement. 
    First digit is main state, second digit is substate */

void fn11(void);
void fn16(void);

void fn24(void);

void fn32(void);
void fn33(void);
void fn35(void);

void main(void)
{
    MainState_t main_state;
    SubState_t sub_state;
    
    for (main_state = State1; main_state < Last_State; main_state++)
    {
        for(sub_state = SubState1; sub_state < Last_SubState; sub_state++)
        {
            demo(main_state, sub_state);
        }
    }
}

void demo(MainState_t State,  SubState_t SubState)
{
    switch (State)
    {
        case State1:
            switch (SubState)
            {
                case SubState1:
                fn11();
                break;
                
                case SubState6:
                fn16();
                break;
            
                default:
                break;
            }
        break;

        case State2:
            switch (SubState)
            {
                case SubState4:
                fn24();
                break;
    
                default:
                break;
            }
        break;
    
        case State3:
        {
            switch (SubState)
            {
                case SubState2:
                fn32();
                break;
                
                case SubState3:
                fn33();
                break;                
                
                case SubState5:
                fn35();
                break;
    
                default:
                break;
            }
        }
        break;
        
        default:
        break;
    }
}

void fn11(void)
{
    puts("State 1, substate 1");
}

void fn16(void)
{
    puts("State 1, substate 6");
}

void fn24(void)
{
    puts("State 2, substate 4");
}

void fn32(void)
{
    puts("State 3, substate 2");
}

void fn33(void)
{
    puts("State 3, substate 3");
}

void fn35(void)
{
    puts("State 3, substate 5");
}

The key points are that we have nested switch statements and the substate is sparse. That is the number of substates for main state 1 is different to that of the substates for main state 2 and so on. If you’ve ever been in the situation of having to write a nested state machine like this, you’ll rapidly find that the code becomes very unwieldy. In particular functions many of hundreds of lines long with break statements all over the place are the norm. The result can be a maintenance nightmare. Of course if you end up going to three levels, then the problem compounds. Anyway, before looking at a pointer to function implementation, here’s the output from the above code:

State 1, substate 1
State 1, substate 6
State 2, substate 4
State 3, substate 2
State 3, substate 3
State 3, substate 5

In addition, using IAR’s AVR compiler, the code size with full size optimization is 574 bytes and the execution time is  2159 cycles, with the bulk of the execution time taken up by the puts() call.

Let’s now turn this into a pointer to function implementation. The function demo becomes this:

void demo(MainState_t State,  SubState_t SubState)
{
    static void (* const pf[Last_State][Last_SubState])(void) = 
    {
        {fn11, fnDummy, fnDummy, fnDummy, fnDummy, fn16},
        {fnDummy, fnDummy, fnDummy, fn24, fnDummy, fnDummy},
        {fnDummy, fn32, fn33, fnDummy, fn35, fnDummy}
    };
    
    if ((State < Last_State) && (SubState < Last_SubState))
    {
        (*pf[State][SubState])();
    }
}

Note that the empty portions of the array are populated with a call to fnDummy(), which as its name suggests is a dummy function that does nothing. You can of course put a NULL pointer in the array, and then extract the pointer, check to see if its non-NULL and call the function, However in my experience its always faster to just call a dummy function.

So how does this stack up to the nested switch statements? Well as written, the code size has increased to 628 bytes and cycles to 2846. This is a significant increase in overhead. However the code is a lot more compact, and in my opinion dramatically more maintainable. Furthermore, if you can guarantee by design that the parameters passed to demo() are within the array bounds (as is the case with this example), then you can arguably dispense with the bounds checking code. In which case the code size becomes 618 bytes and the execution time 2684 cycles. It’s your call as to whether the tradeoff is worth it.