• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 833 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Issue with interrupts when running boot program from NAND flash

Trinh Huu Truong
Prodigy 50 points
Part Number: PROCESSOR-SDK-OMAPL138
Other Parts Discussed in Thread: OMAPL138, OMAP-L138

Hi everybody,

Currently, I am working on OMAP L138, and OMAPL138_StarterWare_1_10_04_01's library.

I need to use interrupts in boot program run on C674x DSP. When I build it on ccs v6.2.0 and run debug, the interrupt is still working and running normally. But when creating .ais files from the .out file and loading the code into nand, the program does not run. I logged by using uart and found the program stopped at the command line:

ISTP = (unsigned int) _intcVectorTable;
This command is in the "void IntDSPINTCInit (void)" function of the interrupt.c file.

Declare the _intcVectorTable function found in the "intvecs.asm" file.
       .align 1024
_intcVectorTable:
       VEC_ENTRY _c_int00
       VEC_ENTRY _c674x_nmi_isr
       VEC_ENTRY _c674x_rsvd_int2_isr
       VEC_ENTRY _c674x_rsvd_int3_isr
       VEC_ENTRY _c674x_mask_int4_isr
       VEC_ENTRY _c674x_mask_int5_isr
       VEC_ENTRY _c674x_mask_int6_isr
       VEC_ENTRY _c674x_mask_int7_isr
       VEC_ENTRY _c674x_mask_int8_isr
       VEC_ENTRY _c674x_mask_int9_isr
       VEC_ENTRY _c674x_mask_int10_isr
       VEC_ENTRY _c674x_mask_int11_isr
       VEC_ENTRY _c674x_mask_int12_isr
       VEC_ENTRY _c674x_mask_int13_isr
       VEC_ENTRY _c674x_mask_int14_isr
       VEC_ENTRY _c674x_mask_int15_isr


I have tried changing the address of "_intcVectorTable" when adding the .sect ".intvecs" line, to put it in the DRAM area but it still does not run.

Is the problem is that the program can not find the address of the interrupt vector table. Can you please guide me how to solve this problem.

  • 0
    TI__Guru 65405 points
    The team is notified. They will post their feedback directly here.

    BR
    Tsvetolin Shulev
  • 0
    TI__Mastermind 27355 points

    Hi Trinh,

    StarterWare is legacy software that is no longer being maintained or supported by TI. The current supported software offering is Processor SDK. It may be downloaded from the following link.

    http://www.ti.com/tool/PROCESSOR-SDK-OMAPL138

  • 0
    Guru 26430 points
    I am unclear about your situation. Are you are running code on the DSP processor of an OMAP-L138 chip? That chip is ARM boot. DSP code will not run.
  • 0 in reply to Norman Wong
    Prodigy 50 points

    Hi Norman Wong,

    I'm using omap secure chip. It uses DSP boot. I have found a similar issue: e2e.ti.com/.../255371. But I do not understand Andrew's reply: "I was not including a" boot "directive for the section that holds the table vector, so it was not added to my hex file. flash. " . How can I "including the "boot" directive for the section that holds the vector table ".

    Thanks,

  • 0 in reply to Sahin Okur
    Prodigy 50 points
    Hi Sahin,

    My boot program does not use Linux or RTOS, it only uses the while loop. But I can not use interrupts for this boot program.

    Thanks,
  • 0 in reply to Trinh Huu Truong
    Guru 26430 points
    I'm not quite convinced the OMAP-L138 is DSP boot. When I say "boot" I mean the user boot loader. Not the first bootloader from ROM. For years, I wondered which processor was used for the first boot. Recent documentation now gives a few sentences that the first boot is the DSP from internal ROM and then control is passed off to the user code in the ARM. That said, I have never used the secure part and maybe TI change the boot order for that part.

    Easy enough to test. Write an program that blinks a LED in a busy spin loop. No interrupts. Compile it for ARM and DSP. Try each.

    I believe the boot directive is just a section name. It could be anything. It sounds like that the muilt-core DSP chips use a vector table at a fixed address. The boot section name is probably used in the linker file to ensure that the vector table is at the right spot. For the C6748 DSP, the vector table address is not fixed. The initiailization code will set the vector table pointer at runtime.