• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 798 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DSP interrupt via syslink example on OMAPL138

Omin Chou
Genius 3555 points

Hi all,

Here is my environment.

1. mcsdk_1_01_00_02

2. bios_6_35_01_29

3. c6000_7.4.2

4. ipc_1_25_03_15

5. syslink_2_21_01_05

6. xdctools_3_25_00_48

I based on ex02_messageq (syslink example) to initialize I2C, McASP, AIC3106 and Interrupt on DSP side. Then I added LED control to make sure McASP EDMA (chunk) interrupt was generated. The behavior was normal when I exacted first run. But the interrupt was gone after I did the second run. 

Here is my test steps.

1. cd /ex02_messageq/debug

2. ./slaveloader startup DSP server_dsp.xe674 // LED is twinkling, but the second run LED is no response

Attached to slave procId 0.
Loading procId 0.
Loaded file server_dsp.xe674 on slave procId 0.
Started slave procId 0.

3. ./app_host DSP //  syslink between ARM and DSP is workable ( also include DSP McASP)

--> main:
--> Main_main:
--> App_create:
App_create: Host is ready
<-- App_create:
--> App_exec:
App_exec: sending message 1
App_exec: sending message 2
App_exec: sending message 3
App_exec: message received, sending message 4
App_exec: message received, sending message 5
App_exec: message received, sending message 6
App_exec: message received, sending message 7
App_exec: message received, sending message 8
App_exec: message received, sending message 9
App_exec: message received, sending message 10
App_exec: message received, sending message 11
App_exec: message received, sending message 12
App_exec: message received, sending message 13
App_exec: message received, sending message 14
App_exec: message received, sending message 15
App_exec: message received
App_exec: message received
App_exec: message received
<-- App_exec: 0
<-- Main_main:
<-- main:

4. ./slaveloader shutdown DSP

Stopped slave procId 0.
Unloaded slave procId 0.
Detached from slave procId 0.

Attached sample code:

https://dl.dropboxusercontent.com/u/12447225/DSP/ex02_messageq.tar.gz

My queries are:

1. Am I right to use this method to check interrupt on DSP side? Or have any better way to do such verification?

2. Which steps I miss to set in my sample code that result SW interrupt not happened at second run?

Thanks in advance.

B.R.

OC

  • 0
    TI__Mastermind 35645 points

    Hi,

    Thanks for your post.

    I thinks, there are steps to be followed when you let debug into the application's C-source code in CCS provided when you load the debug version If you are running any of the examples provided in SysLink (e.g. ex02_messageQ) as below:

    1. On the ARM, ./slaveloader_debug startup DSP server_dsp.xe674 to load and start the DSP

    2. Connect CCS to the DSP, set a breakpoint in ti_sdo_ipc_Ipc_procSyncFinish and then let it resume running.

    3. Now run app_host DSP on the ARM side which will call Ipc_control(Ipc_CONTROLCMD_STARTCALLBACK), which will should get teh DSP to run Ipc_attach() etc.

    Subsequently, Ipc_attach() is called, who should set a few bits and wait for the host-side application to also set some bits at the top of the SharedRegion 0 (e.g. @ address 0xc600000 in example below) for handshaking.  Address of SR0 will depend on your DSP-side application's configuration.

    May be, for more info. please refer the below E2E post:

    https://e2e.ti.com/support/embedded/tirtos/f/355/p/261836/917395#917395

    Thanks & regards,

    Sivaraj K

    -------------------------------------------------------------------------------------------------------

    Please click the Verify Answer button on this post if it answers your question.

    -------------------------------------------------------------------------------------------------------

  • 0 in reply to Sivaraj Kuppuraj
    Genius 3555 points

    Hi Sivaraj,

    Thanks for your prompt reply.

    I followed your method to double check that seemed DSP interrupt (procBuffer) never trigger once finished slaveloader shutdown DSP.

    Could you please provide some hints to me? Thanks a lot

    Here are related printscreen for the reference.

    1. Ipc_attach called ti_sdo_ipc_Ipc_procSyncFinish

    2. View 0xC6000000 for handshaking status

    B.R.

    OC

  • 0 in reply to Omin Chou
    Genius 3555 points
    Hi Sivaraj,

    Any idea could share with me? Thanks a lot.

    B.R.
    OC
  • 0 in reply to Omin Chou
    TI__Guru** 116100 points
    Dear OC,

    I based on ex02_messageq (syslink example) to initialize I2C, McASP, AIC3106 and Interrupt on DSP side. Then I added LED control to make sure McASP EDMA (chunk) interrupt was generated. The behavior was normal when I exacted first run. But the interrupt was gone after I did the second run.

    Not an expert in SYSLINK, though, I'm suspecting in freeing the resources (delete phase, ex "App_delete") while first run, it may cause the problem while running second time, so you can use only LED related interrupt code and make sure that you are freeing the interrupts properly then try to run second time and check.