Interrupt vector for IRQ and FIQ on AM35x

hI MATT

hi matt!!!

can u send me some link to download a free trial version of RVDS 4.1 or any other compiler with which i can simulate my cortex A8 c language code.

hrishikeshchoudhary23@gmail.com

I am not a TI employee.  You have the same access to everything that any other public user has.

I suggest you write your own post asking for that, instead of asking me.

TI guys,

The crickets are VERY loud in here...

Hi Matt,

the first few steps in Section 8.5.2 is trying to describe what is happening between the Interrupt Controller and the MPU core.  Since there are a myriad of interrupt sources and only a couple of interrupts on the core, there must be some management of the signals.   This only applies to IRQ and FIQ.  Since Undefined, abort, etc. are more exceptions rather than interrupts, there is no interrupt processing relative to those.  Just the exception vector is taken immediately.

The addresses 0x14000-0x1401C are the ROM exception vectors, and the 0x4020FFC8-0x4020FFE0 are the RAM expection vectors.  The RAM exception vectors can be modified if you want to redirect any of the vectors to a user defined handler (see sec 24.4.2 for more explanation). 

I'm not sure where the reference for 0xFFFF0018 or 0x00000018 comes from.  This may very well come from the interrupt controller spec which may not be specifically applicable to AM35x device.  On Cortex-A8, you can specify a  Vector Base Address in the ARM core using MCR p15,0,r1,c12,c0,0 (see the ARM user's guide for more info on core register accesses), so your interrupt vectors can reside anywhere.

I've tried to answer some of your other questions below.

Regards,

James

MATT GESSNER said:

SPRUGR0B is conflicting when it is describing how interrupts are handled.

I haven't been able to find any other information on this topic.

When booting out of SRAM, the interrupt vectors are set to points in the ROM code:

0x14000, reset entry point into ROM code

0x14004, LDR PC,0x4020FFC8 (part of the internal SRAM) for Undefined Exception

0x14008, LDR PC,0x4020FFCC for SWI

0x1400C, LDR PC,0x4020FFD0 for Prefetch abort

0x14010, LDR PC,0x4020FFD4 for Data abort

0x14014, LDR PC,0x4020FFD8 for Unused (?)

0x14018, LDR PC,0x4020FFDC for IRQ

0x1401C, LDR PC,0x4020FFE0 for FIQ

So if I want to handle one of those interrupts, I would write the address of the handler to one of the addresses in the range 0x4020FFC8-0x4020FFE0.

Great, fine, wonderful, dandy.

What's not clear is how I would handle an IRQ or an FIQ in this mode, because section 8.5.2 says that when INCPS_MIRn and INTCPS_ILRm register are configured to enable and assign priorities to incoming interrupts, the interrupts are processed MUCH differently.  NOTE: that doesn't mean ANYTHING for Undefined, SWI, Prefetch/Data abort, etc.  What gives?  Is this just documented incorrectly?  I can't find any explanation for this anywhere.  When I look for interrupt or IRQ on the processor wiki, I seem to come up dry.

[James]  So IRQs and FIQs are handled differently than the other exceptions.  There are a couple of flow charts in the TRM describing what happens with an IRQ/FIQ.  You can consider the other ones to be taken immediately without any other hardware interaction.

So if I take an IRQ or FIQ interrupt, whether I'm in SRAM or in SDRAM, what really happens?

[James]  Once the interrupt gets to the ARM core, the procedure the h/w take is the same, no matter where the vector resides.

MORE IMPORTANTLY, what happens AFTER I'm no longer running from SRAM?  Where do I configure the vectors for IRQ and FIQ?  The pseudo code says either 0xFFFF0018 or 0x00000018 for IRQ (depending on if high vectors are selected or not), or 0xFFFF001C or 0x0000001C for FIQ

[James]  Ignore the addresses in the pseudo code.  The vectors are configured in the Vector Base Address in the ARM core registers.

Finally, since the address map is pretty well fixed, how do I put a value into 0xFFFF0018 or 0x00000018 or 0xFFFF001C or 0x0000001C?

[James]  These addresses are not applicable.  You can use the RAM exception vectors.  Section 24.4.2.2 describes this.

There doesn't appear to be any memory there.  The memory map for the part shows that 0x00000000 is part of the GPMC.  0xFFFFxxxx is part of  EMIF4/SMS virtual address space 1, which I don't believe I'm using.  SDRAM is from 0x80000000 to 0xBFFFFFFF.

[James]  There is probably a little confusion in the memory map as it is laid out in the TRM.  The first 1MB of 0x00000000 is actually redirected to the on-chip boot ROM at 0x40000000 if booting from the ROM.  When booting from GPMC, 0x00000000 address is available on CS0 to be able to boot from external memories.  So with the exception of GPMC booting, the first 1MByte of the memory map is not available for use as GPMC. 

 

Lastly, what's the deal with the locations of the boot ROM code?  They're not the same.  Section 24 says 0x14000, which conflicts with the GPMC, but the Global Memory Space Mapping says 0x40014000 is the start of the public boot ROM code.  The debugger (which STILL isn't working correctly, if anyone but James cares), shows exceptions running from 0x140080 - 0x1401C.

[James]  Thanks for the shout out.  I think you are seeing the redirect in the debugger.  So 0x14000 will look the same as 0x40014000 (and similarly for the first 1MB). 

Also, perhaps it's documented elsewhere, but I haven't seen it... this chip does not have a DSP in it, despite what SPRUGR0B says in the GPIO module.

[James]  Yes, this is a consequence of reusing documentation.  We reused the OMAP35x TRM for much of this one, and some references to the DSP are scattered throughout each chapter.  We try to rely on Ch1 to describe these differences. 

Hi, James,

Thanks for taking the time to read and respond and confirm what I was hoping.  Thanks for tipping me off to the exception vector base address.

I was able to confirm that the VBR is indeed 0x14000 by doing MRC p15,#0x0,r0,c12,c0,#0x0

Thanks again for your valuable help!

Matt

Hi All

i am facing the problem,regarding interrupt handling in omap3530( core : cortex A8) in u-boot level with (#define CONFIG_USE_IRQ        1)

Source:

In start.S ,where it is relocation vector table to SRAM address 0x4020F800

#if defined(CONFIG_OMAP34XX)
    /* Copy vectors to mask ROM indirect addr */
    adr    r0, _start        @ r0 <- current position of code
    add    r0, r0, #0        @ skip reset vector ( I have changed to zero from  default 4)
    mov    r2, #64        @ r2 <- size to copy
    add    r2, r0, r2        @ r2 <- source end address
    mov    r1, #SRAM_OFFSET0    @ build vect addr
    mov    r3, #SRAM_OFFSET1
    add    r1, r1, r3
    mov    r3, #SRAM_OFFSET2
    add    r1, r1, r3
   
next:
    ldmia    r0!, {r3 - r10}        @ copy from source address [r0]
    stmia    r1!, {r3 - r10}        @ copy to   target address [r1]
    cmp    r0, r2            @ until source end address [r2]
    bne    next            @ loop until equal

include/arch/arm/omap3.h

/* base address for indirect vectors (internal boot mode) */
#define SRAM_OFFSET0            0x40000000
#define SRAM_OFFSET1            0x00200000
#define SRAM_OFFSET2            0x0000F800
#define SRAM_VECT_CODE            (SRAM_OFFSET0 | SRAM_OFFSET1 | \
                     SRAM_OFFSET2)

#define LOW_LEVEL_SRAM_STACK        0x4020FCAC //0x4020FFFC

i added,

cpu_init_crit:
    /*
     * Invalidate L1 I/D
     */
    mov    r0, #0            @ set up for MCR
    mcr    p15, 0, r0, c8, c7, 0    @ invalidate TLBs
    mcr    p15, 0, r0, c7, c5, 0    @ invalidate icache

    /*
     * disable MMU stuff and caches
     */
    mrc    p15, 0, r0, c1, c0, 0
    bic    r0, r0, #0x00002000    @ clear bits 13 (--V-)
    bic    r0, r0, #0x00000007    @ clear bits 2:0 (-CAM)
    orr    r0, r0, #0x00000002    @ set bit 1 (--A-) Align
    orr    r0, r0, #0x00000800    @ set bit 12 (Z---) BTB
    mcr    p15, 0, r0, c1, c0, 0
   
    mov    r0, #0                         //added
    ldr    r0,  =0x4020F800    //added to say about vector table location to co processsor
    
    mcr p15, 0, r0, c12, c0, 0  //added to say about vector table  location to co processsor

    /*
     * Jump to board specific initialization...
     * The Mask ROM will have already initialized
     * basic memory. Go here to bump up clock rate and handle
     * wake up conditions.
     */
    mov    ip, lr            @ persevere link reg across call
    bl    lowlevel_init        @ go setup pll,mux,memory
    mov    lr, ip            @ restore link
    mov    pc, lr            @ back to my caller

interrupt hadler in interrupts.c in lib_arm

void do_irq (struct pt_regs *pt_regs)
{
    disable_interrupts();   
    show_regs (pt_regs);
      printf ("irq interrupt request\n");
 
}

When external interrupt is generated

irq interrupt request                                                          
pc : [<80e8b4c0>]          lr : [<00000000>]                                   
sp : 00000000  ip : 80eb3884     fp : 80e3de8c                                 
r10: 00000008  r9 : 80eac6d2     r8 : 80e3ffe0                                 
r7 : 80eb3984  r6 : 80e3de88     r5 : 80eb3984  r4 : 80e3def4                  
r3 : 00000060  r2 : 00000002     r1 : 00000003  r0 : 49020000                  
Flags: nZcv  IRQs on  FIQs off  Mode SVC_32    

Interrupt soure:

GPIO(14) on falling edge(internal pull up enable) with unmask  interrupt enable----> at gpio module

At Interrupt controller:

MPU Subsystem INTCPS:

31:0 MIR Type Interrupt mask
Reset
RW 0xFFFFFFFF
0x1: The interrupt is masked
0x0: The interrupt is unmasked

29 bit is corresponding to GPIO1 interrupt ,i am claering

Problem:

But it will dislay the same continuously(infinite)

Let any one suggest some inputs & solution to slove this problem.

Thanks for helping