This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Interrupt vector code missing

I have project that includes a '.lib' file. The library
contains separate modules like adc.c, i2c.c, tmr.c...

The interrupt routines are placed in their corresponding modules. The interrupt vectors are created for the adc and i2c modules just fine, but the timer isr vector's are not there when looking at the disassembly. The interrupt functions are present
in the code just not the 'LJMP' at 0x0B and 0x1B. I've tried moving around the order of the functions, and removing all but the interrupt code but the interrupt vectors are still not added.

Has any one seen this before or having any suggestions
to fix this?

Example:

///adc.c

#pragma nomodp2
void adc_isr() interrupt 14
{
        ADCON1 = (ADCON1 & 0xF7);
        ADCON0 = (ADCON0 & 0xF7);
}
#pragma modp2

///tmr.c

#pragma nomodp2
void timer_zero_isr () interrupt 1 using 2
{
    MISO = ~MISO;
    puts ("tmr zero intrpt");
    TF0 = 0;
}

void timer_one_isr () interrupt 3 using 2
{
    if (TF1)
        puts ("tmr one intrpt");
}
#pragma modp2

C_STARTUP:
C:0x0000 0213A0 LJMP C:13A0
C:0x0003 00 NOP
C:0x0004 00 NOP
C:0x0005 00 NOP
C:0x0006 00 NOP
C:0x0007 00 NOP
C:0x0008 00 NOP
C:0x0009 00 NOP
C:0x000A 00 NOP
C:0x000B 00 NOP
C:0x000C 00 NOP
C:0x000D 00 NOP
C:0x000E 00 NOP
C:0x000F 00 NOP
C:0x0010 00 NOP
C:0x0011 00 NOP
C:0x0012 00 NOP
C:0x0013 00 NOP
C:0x001B 00 NOP
C:0x001C 00 NOP
C:0x001D 00 NOP ...

C:0x0022 00 NOP
C:0x0023 020C73 LJMP uart_isr(C:0C73)
C:0x0026 00 NOP
C:0x0027 00 NOP ...

C:0x0031 00 NOP
C:0x0032 00 NOP
C:0x0033 0209E9 LJMP i2c_isr(C:09E9)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
P89LPC935
IDE-Version:
µVision3 V3.30a
Tool Version Numbers:
Toolchain Path: C:\Keil\C51\BIN\
C Compiler: C51.Exe V8.02
Assembler: AX51.Exe V3.01
Linker/Locator: LX51.Exe V4.05
Librarian: LIBX51.Exe V4.24

Parents
  • The problem is that if some project never calls, from the library, the function directly above the ISR (even though other functions in that module are used) then the vector isn't added, even though the actual ISR code is added to the project. Also, putting the ISR at the top of the file didn't help. Which means I would have to put the ISR directly below a function that will
    always be used if that module is used. Now that I think about it, placing the ISR directly behind the initialization functions would be a good place for most modules but not all modules will need a function like that.


    "however that will lead to very unstructured code."

    What do you mean? What kind of problems could I run into?

Reply
  • The problem is that if some project never calls, from the library, the function directly above the ISR (even though other functions in that module are used) then the vector isn't added, even though the actual ISR code is added to the project. Also, putting the ISR at the top of the file didn't help. Which means I would have to put the ISR directly below a function that will
    always be used if that module is used. Now that I think about it, placing the ISR directly behind the initialization functions would be a good place for most modules but not all modules will need a function like that.


    "however that will lead to very unstructured code."

    What do you mean? What kind of problems could I run into?

Children
  • placing the ISR directly behind the initialization functions would be a good place for most modules but not all modules will need a function like that.

    if all I/O modules have an "initialization functions" the what is the proble? just insert an 'empty' in those that do not need it for other reasons.

    "directly below " is nonsense, as long as omething anywhere in the module is called it works.

    "however that will lead to very unstructured code."
    What do you mean? What kind of problems could I run into?

    I replied to
    Placing each ISR function in a seperate file seems to work.
    if you have the ISR and the function that process the result in two different modules I'll call the code unstructured.
    "What kind of problems could I run into?" readability and ease of maintenance. For instance if you have a circular buffer the two offsets need be known to both the ISR and the 'user'. If the ISR and the 'user' are in two different modules the code is less readable and the two offsets need be global.

    Erik