Exceptions, interrupts and startup

man-1633667_1280

Welcome to the latest instalment of my blog!

As I promised last time, in this post I’ll be getting into the nitty-gritty of the startup file t4mc123gh6pm_startup_ccs.c – the code that is compiled along with main.c in order to produce the final working .out file. Before I do that, though, I need to say a few words on the subject of exceptions and interrupts.

In most embedded microcontroller applications it is likely that the micro will be receiving input from the outside world in some way. This communication may take the form of user input (from a keyboard or touchscreen, for example), input from sensors (thermocouples, level sensors, etc.) or communications via USB, the I2C bus, or whatever. All of these inputs will be presented as signals on the micro’s various input pins, and even for a simple micro there may be a wide variety of different inputs to deal with.

When a new input presents itself, for example if the user presses a key on a keyboard, the micro is required to suspend whatever it was doing at the time and deal with the new input, before returning to its previous task.

Some would classify this event as an “exception”, because it represents an exception to what the micro would normally be doing. Others would term the event an “interrupt” for similar reasons. Still others would consider interrupts to be a sub-category of exception – there doesn’t appear to be any standardization in terminology, and you have to think carefully about what is being discussed in any given case. For the sake of consistency I will use the definitions found in Steve Furber’s book “ARM System-on-Chip Architecture”, Section 5.2:

“… Exceptions are usually used to handle unexpected events which arise during the execution of a program, such as interrupts or memory faults. In the ARM architecture the term is also used to cover software interrupts and undefined instruction traps (which do not really qualify as ‘unexpected’) and the system reset function which logically arises before rather than during the execution of a program (although the processor may be reset again while running). These events are all grouped under the ‘exception’ heading because they all use the same basic mechanism within the processor.[1]

This is consistent with the view expressed in the Texas instruments TM4C123GH6PM Microcontroller datasheet, Section 2.5.2., “Exception types”, which I interpret as:

  • Exception: Reset, NMI, Hard Fault, Memory Management Fault, Bus Fault, Usage Fault, SVCall, Debug Monitor, PendSV and SysTick – also known as “system handlers”.
  • All other exceptions, not falling within the “Exception” category above.

For ease of reading, I’ll refer to “interrupts” from now on unless specifically talking about one of the system handler exceptions.

So what happens when the micro encounters an interrupt? The simplified sequence of events is as follows:

  1. The current instruction is allowed to complete
  2. The contents of various registers are written (or “pushed”) to an area of memory known as the “stack”, creating a record of the micro’s state before the interrupt occurred
  3. Depending on the nature of the interrupt, program execution jumps to the appropriate Interrupt Service Routine (ISR) – the piece of code responsible for dealing with the particular interrupt. The locations of the ISRs are stored on a “vector table”
  4. The ISR is executed
  5. Once the ISR is completed, the previous system state is returned to by “popping” the register contents from the stack

The micro will then carry on with what it was doing before the interrupt occurred, until the next interrupt arrives.

The t4mc123gh6pm_startup_ccs.c startup file is largely (though not exclusively) concerned with exceptions/interrupts, hence my wish to comment on the subject first before diving in to the analysis. As before, it’s easier to document that analysis in a linked PDF file, which you can see here:

Exceptions, interrupts and startup

I’ve realised that I’ve written quite a few thousand words now without progressing beyond the simple “Flash 3 LEDs in Sequence” program in the LaunchPad Workbook. I guess that shows just how much detail lies behind the creation of even such a simple program! In my next post, though, I’ll be moving on to Lab 4 of the Workbook, a whole new program, and taking a closer look interrupts and the micro’s built-in timers.

 

Chris.

[1] Furber, S (2000). ARM System-on-Chip Architecture. Addison Wesley. Section 5.2, p108.