This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

ARM Interrupts jumping to 0x00000000



Until now i have mostly been using the DSP core on the L138, but now i hit a problem while trying to get in to this supervisor mode because i needed to mess with the system registers, but found that the code crashes at the _call_swi() function. After some debugging i found that the interrupt jumps to 0x00000008 so the correct software interrupt vector if the table was located at address 0x0. The documetation tells me that by default the ISR table is at 0xFFFF0000 that is the beginning of ARM ram.(I read about the bit that causes this but i need to already be in supervisor mode to change that bit)

So to make sure its not my code messing it up i tried to run the timer interrupt example from the rCSL2 library with the same results, and also booting the chip in JTAG mode to make sure uBoot is not doing this, even tried to compile and debug run the example on my laptop with the same result.

I am using the hawkboard to run my code. Can anyone suggest why the ARM wants to use the ISR table at 0x0 instead the supposedly default 0xFFFF0000 ?

  • Nevermind already solved it. It seams that uboot causes it to switch in to this, but also found a strange quirk that if i leave the XDS100v2 connected it refuses to change boot modes and just stays in the same one after pressing the reset button so i likely was not really in JTAG boot when i set the dip switch to that. No idea how that can happend but it does.

    I found a lot of useful information in this thread before finding out this boot quirk:

    http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/120595.aspx