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.

PROCESSOR-SDK-OMAPL138: Can't access the ISTP register in the boot program

Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAPL138

Dear TI team,


I am developing a device using OMAPL138 processor.
I want to access to the ISTP register to set the interrupt vector table pointer.
I read and followed the "Example 6-1 Relocation of Interrupt Service Table" in "Section 6.1.1.6 Interrupt Service Table Pointer (ISTP)". Document SPRUGH7 November 2010.
When I run this example in the program in debug mode, I can access normally the ISTP register. But when executing programs by booting from NAND, access to this register is not possible. The program is hung. I have checked the TSR.CMX before accessing the ISTP and found it to be 00 (supervisor mode).

The program runs on C674x DSP and the address I wrote to ISTP is 0x00800000.

Could you please help me to resolve this issue?

Thanks,

Truong

  • The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • Please respond to me asap. This is an important part of my project.

    BR
    Truong

  • The document SPRUGH7 November 2010 applies to C66x DSP so I would recommend that you refer to C674x Megamodule guide instead.

    Checkout Tim`s suggestion here for C64x+, this should also apply to C674x DSP.
    e2e.ti.com/.../58982

    Could you provide the code that you used in debug mode to access setup ISTP. Are you using C6x.h as per above discussion.

    OMAPL138 is an ARM boot device so there is no setting up of any ISTP by ROM bootloader, unless you have a secondary bootloader that is setting up ISTP, this should be at reset value even when you try to configure it after NAND boot. Could you try an experiment. Can you configure the device in NAND boot and then idle the DSP core and then try to load the same binary that you used for debug and see if you see the same behavior.

    Regards,
    Rahul