Electronic – Cortex M0 – Defining an interrupt routine in assembly

armassemblyinterrupts

For a project I have some code that needs to be written in assembly due to precise timing requirements. I'd ideally like to implement my code in a timer interrupt routine. Right now, in C++ I can define an ISR as such:

extern "C" void TIM3_IRQHandler(void)
{
//code here
}

I'm using an STM32F030 chip, which from the datasheet shows that the Timer3 IRQ address is 0x00000080. My understanding is that there is an address stored at this location that marks the start of the interrupt handler.

How do I change the address at the above entry to point to the start address of my assembly code so that I can handle the interrupt in assembly? I know I can technically put inline assembly within the C function above, but there must be a way to handle the interrupt entirely in assembly.

I should note that I'm using the GNU ARM toolchain

Best Answer

How do I change the address at the above entry to point to the start address of my assembly code so that I can handle the interrupt in assembly?

Asssuming default startup, just declare the function with the correct name in assembler:

.syntax unified
.thumb
.arch armv6m
.text

.global TIM3_IRQHandler
  .thumb_func
TIM3_IRQHandler:
  BX LR
.end

Note: This example will deadlock (read: infinitely tail-chain), since the timer flags are not resetted properly.

Related Solutions

Electronic – avr-gcc timer overflow interrupt handler in inline assembly

I found you post when I was looking for optimization of ISR routine. Finally, I've got a solution which you (and I) wanted to get.

I use Atmel Studio 6.1 (GCC 3.4.2.1002)

ISR(TIM0_OVF_vect,ISR_NAKED)
{
    asm volatile(
        "push   r24"            "\n"
        "in     r24, __SREG__"  "\n"
        "push   r24"            "\n"
        "push   r25"            "\n"

        "lds    r24, %A[_ts]"   "\n"
        "lds    r25, %B[_ts]"   "\n"
        "adiw   r24,1"          "\n"
        "sts    %B[_ts], r25"   "\n"
        "sts    %A[_ts], r24"   "\n"

        "pop    r25"            "\n"
        "pop    r24"            "\n"
        "out    __SREG__,r24"   "\n"
        "pop    r24"            "\n"
        "reti"                  "\n"
        : 
        : [_ts] "m" (ts)
        : "r24", "r25"
    );
}

Here ts is declared as volatile unsigned int ts = 0;
I use named operands ([_ts] "m" (ts)) instead of defailt %0

The result is:


    0000005a <__vector_11>:
    5a: 8f 93           push    r24
    5c: 8f b7           in  r24, 0x3f   ; 63
    5e: 8f 93           push    r24
    60: 9f 93           push    r25
    62: 80 91 60 00     lds r24, 0x0060
    66: 90 91 61 00     lds r25, 0x0061
    6a: 01 96           adiw    r24, 0x01   ; 1
    6c: 90 93 61 00     sts 0x0061, r25
    70: 80 93 60 00     sts 0x0060, r24
    74: 9f 91           pop r25
    76: 8f 91           pop r24
    78: 8f bf           out 0x3f, r24   ; 63
    7a: 8f 91           pop r24
    7c: 18 95           reti

Electronic – Managing addresses of interrupt service routines and functions of the program in cortex M0

The common approach is to make a const array that contains the appropriate values (initial SP, initial PC = adress of init code, addresses of the interrupt service routines) and use some compiler-dependant magic to force the linker to place this array at address 0.

An example in gcc (from my http://www.voti.nl/bmptk):

void (* const __vectors[ 8 ])(void) 
__attribute__ ((section(".vectors"))) = {
   (void (*)(void)) & __stack_end,  
   __startup,
   // interrupt verctors etc.
};

The __ attribute__ ((section(".vectors"))) marks this array as part of a section called "vectors". The matching linkerscript ensures that that section is placed first in the flash memory:

MEMORY
{
   rom (rx)     : org = ROM_START, len = ROM_SIZE
   ram (rwx)    : org = RAM_START, len = RAM_SIZE
   nul (rwx)    : org = 0x20000000, len = 0k
}
. . . 
SECTIONS
{
   .text :
   {

       . = ALIGN(4);
       KEEP(*(.vectors));
       . . .
       # other sections come here  (= the rest of your code)

In normal situations this is something that your tool vendor/builder/creator has done for you.

Best Answer

Related Solutions

Electronic – avr-gcc timer overflow interrupt handler in inline assembly

Electronic – Managing addresses of interrupt service routines and functions of the program in cortex M0

Related Topic