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

ARM1136 - Not Jumping to ISR problem

Note: This was originally posted on 6th January 2009 at http://forums.arm.com

Hi,

I am working on ARM1136JF-S Core. I need to implement handling of the interrupts (GPT interrupt) in u-boot bootloader which is not generally done.

For this I followed the following steps
1) mask I/F Bit in cpsr register to enable the IRQ.
2) Set VE bit ( bit 24 ) to 0 in the CP15 register - for fixed vector
3) Set V bit (bit 13) to 0 to set the address range 0x00000000-0x0000001C


I have called my ISR "IRQ_Handler" also in the appropriate place. The below snippet demonstrates how I am doing the same.

.globl _start
_start: b reset

ldr pc, _undefined_instruction
ldr pc, _software_interrupt
ldr pc, _prefetch_abort
ldr pc, _data_abort
ldr pc, _not_used
ldr pc, _irq
ldr pc, _fiq

_undefined_instruction: .word undefined_instruction
_software_interrupt: .word software_interrupt
_prefetch_abort: .word prefetch_abort
_data_abort:  .word data_abort
_not_used:  .word not_used
_irq:   .word irq
_fiq:   .word fiq

irq:
get_irq_stack
irq_save_user_regs
bl IRQ_Handler
irq_restore_user_regs

With the above snippet and register setting and after enabling the interrupt, I am able to get the interrupt but my board goes to hang state. May be the control is not jumping to the appropriate location after getting the interrupts.

Please let me know if I am missing on something. Would really appreciate some pointers on this.

Thanks in Advance.

-Nikhil
  • Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    Just to confirm: You need to clear the I bit. The F bit is irrelevant if you are using IRQs as it controls FIQs, but you would do best to leave it as it is.


    Do you know where it does jump to? Can you connect a debugger?


    What does "get_irq_stack" do? It is conventional to set up the IRQ stack before enabling IRQs.

    Also, check that you're writing to the correct CP15 register. Indeed, I often get confused with the syntax of the coprocessor instructions. You should be modifying the Control Register, c1.

    Finally, check that your modification of the interrupt behaviour does not conflict with the system. For example, if your system already uses FIQs (or any other exception) for some reason, you will need to take care not to disrupt this behaviour.

    Does that help?
    Jacob


    Hi Jacob,

    Thanks a lot for your reply..
    I am now able to get the interrupt in u-boot!!!
    All the register settings that I mentioned were actually very correct. The problem here was the MMU isn't initialised in u-boot. Hence the vector table is still located in the internal ROM at 0x00000000 which doesn't have correct IRQ handler.

    What is required here is to initialise/enable  the MMU and map my SDRAM to 0x00000000 location where the actual u-boot vector table would now reside and is refered to service interrupt.

    Thanks
    -Nikhil Rao
  • Note: This was originally posted on 13th January 2009 at http://forums.arm.com

    Hi Jacob,

    Thanks a lot for your reply..
    I am now able to get the interrupt in u-boot!!!
    All the register settings that I mentioned were actually very correct. The problem here was the MMU isn't initialised in u-boot. Hence the vector table is still located in the internal ROM at 0x00000000 which doesn't have correct IRQ handler.

    What is required here is to initialise/enable  the MMU and map my SDRAM to 0x00000000 location where the actual u-boot vector table would now reside and is refered to service interrupt.

    Thanks
    -Nikhil Rao


    Hi Nikhil,

    I went through the same problem few months back. This is how i solved.
    i added a vector setup code in the boot loader(our custom boot loader).
    In the Vector Setup code: I have hard-coded opcode 0xE59FF018 to the locations 0x0000:0000 - 0x0000:001C
    and start of SDRAM to the locations 0x0000:0020 to 0x0000:003C, assumption that start of SDRAM contained the jump table mentioned in your code.
    Memory would look like this
    Address                           Content
    0x0000:0000 :  0xE59FF018
    0x0000:0004 :  0xE59FF018
    0x0000:0008 :  0xE59FF018
    0x0000:000C : 0xE59FF018
    0x0000:0010 :  0xE59FF018
    0x0000:0014 :  0xE59FF018
    0x0000:0018 :  0xE59FF018
    0x0000:001C : 0xE59FF018
    0x0000:0020 :  0x09000000
    0x0000:0024 :  0x09000004
    0x0000:0028 :  0x09000008
    0x0000:002C : 0x0900000C
    0x0000:0030 :  0x09000010
    0x0000:0034 :  0x09000014
    0x0000:0038 :  0x09000018
    0x0000:003C : 0x0900001C

    Meaning of Opcode 0xE59FF018 is ldr PC, [PC+0x18]

    Make sure your code snippet lied at the start of SDRAM(here 0x09000000)
    _start: b reset

    ldr pc, _undefined_instruction
    ldr pc, _software_interrupt
    ldr pc, _prefetch_abort
    ldr pc, _data_abort
    ldr pc, _not_used
    ldr pc, _irq
    ldr pc, _fiq

    This should Work Fine.
    Enabling MMU before setting Pagetables may cause certain problems.

    Regards
    Jack
  • Note: This was originally posted on 6th January 2009 at http://forums.arm.com

    1) mask I/F Bit in cpsr register to enable the IRQ.

    Just to confirm: You need to clear the I bit. The F bit is irrelevant if you are using IRQs as it controls FIQs, but you would do best to leave it as it is.

    With the above snippet and register setting and after enabling the interrupt, I am able to get the interrupt but my board goes to hang state. May be the control is not jumping to the appropriate location after getting the interrupts.

    Do you know where it does jump to? Can you connect a debugger?

    irq:
    get_irq_stack
    irq_save_user_regs
    bl IRQ_Handler
    irq_restore_user_regs

    What does "get_irq_stack" do? It is conventional to set up the IRQ stack before enabling IRQs.

    Also, check that you're writing to the correct CP15 register. Indeed, I often get confused with the syntax of the coprocessor instructions. You should be modifying the Control Register, c1.

    Finally, check that your modification of the interrupt behaviour does not conflict with the system. For example, if your system already uses FIQs (or any other exception) for some reason, you will need to take care not to disrupt this behaviour.

    Does that help?
    Jacob