Overriding MQX ROM Vector table at compile time, kernel_isr Feature Request

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Overriding MQX ROM Vector table at compile time, kernel_isr Feature Request

1,237 Views
pmt
Contributor V

Greetings,

In the MQX vectors.c file the majority of the vectors are set to a single define, DEFAULT_VECTOR:

    /* Cortex external interrupt vectors                                                */

    DEFAULT_VECTOR,         /* 0x10  0x00000040   -   ivINT_DMA0                        */

    DEFAULT_VECTOR,         /* 0x11  0x00000044   -   ivINT_DMA1                        */

     ...

However, more useful would be if they are set to unique names:

               ; External Interrupts

               DCD     DMA0_DMA16_IRQHandler  ; DMA channel 0/16 transfer complete interrupt

               DCD     DMA1_DMA17_IRQHandler  ; DMA channel 1/17 transfer complete interrupt

               ...

That are set to the default handler with a WEAK export:

Default_Handler PROC

                EXPORT  DMA0_DMA16_IRQHandler     [WEAK]

                EXPORT  DMA1_DMA17_IRQHandler     [WEAK]

               ...

               // default ISR handler

then the user is able to create an override function in the user code like without the need to call run-time kernel interrupt install code.  This is true even if the vector table is left in ROM:

// User kernel ISR C code example

void DMA0_DMA16_IRQHandler(void)

{

     // ISR handler here ...

}

Can you consider this as a modification to the MQX vector BSPs?  It would allow compile time kernel ISR installation that woudl work in ROM or RAM.

Thanks,

PMT

0 Kudos
Reply
4 Replies

560 Views
macl
Senior Contributor I

Hi,

What toolchain are you using?  Any implication across different linkers?  

Thanks for posting.

MacL

0 Kudos
Reply

560 Views
pmt
Contributor V

I'm using the KEIL tool chain.  I suppose there are implications across linkers, but they should be fairly generic.

An example of the vector table can be found as part of the Freescale CMSIS distribution which is produced by Freescale, so I think this would be a natural shoe-in for MQX (file header example below). 

;/*****************************************************************************

; * @file:    startup_MK60F12.s

; * @purpose: CMSIS Cortex-M4 Core Device Startup File for the

; *           MK60F12

; * @version: 1.1

; * @date:    2011-11-3

; *

; * Copyright: 1997 - 2012 Freescale Semiconductor, Inc. All Rights Reserved.

;*

; *------- <<< Use Configuration Wizard in Context Menu >>> ------------------

; *

; *****************************************************************************/

0 Kudos
Reply

560 Views
c0170
Senior Contributor III

Hello pmt,

I noticed you are using KEIL, samples you posted are from assembly file for freescale board, something similar is in CMSIS as well. I have not tested weak linkage with all compilers we support (GCC, GCC, IAR, ARMCC, Kinetis CW compiler).

What would you loose if you don't call run-time function, chaining ISR interrupts, because _int_install_kernel_isr returns pointer to the previous ISR and temporarily assig ISR to a vector.

Regards,

c0170

0 Kudos
Reply

560 Views
pmt
Contributor V

That's true, you would loose the chaining of the MQX default interrupt, but only if the user manually chose to override the out of-the-box MQX default vector table value.  In most cases this is simply the _default_interrupt handler anyway.

The advantages are:

     - That you gain the ability to install user interrupt in a ROM build vector table (this is a definable option under MQX). 

     - No need to run-time install the interrupt vector, though the user still has the option to call _int_install with RAM vector tables.

     - Better aligns with CMSIS which has a lot of value in providing greater portability.

In the end I think this gives the user more flexibility and will maintain default backward compatibility.  Something to consider!

Thanks,

PMT

0 Kudos
Reply