• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 99 subscribers
  • Views 548 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.

help on DSPLink application

Kevin43482
Prodigy 200 points

I modified the message sample code for my own application.   GPP loads DSP.  DSP sends a message to GPP, then it waits for a message from GPP. Once DSP receives the message, it executes TSKMESSAGE_delete.  It ran correctly before I added my own code.  If TSKMESSAGE_execute() (in DSP)  calls my own function, the code (in GPP) appears to be stuck at the MESSAGE_delete() in GPP .   The following is the stdout output.   The code hangs at the line "tmpStatus = MSGQ_transportClose(0)".  From the message sent by DSP, my DSP code (a  complex DP floating point algorithm) is correct.  Well, at least its output is the expected result.  

 

Thanks a lot!

 

Entered MESSAGE_Create ()
Leaving MESSAGE_Create ()

Entered MESSAGE_Execute ()

Entering MESSAGE_VerifyData

Display the received data from DSP. 
Leaving MESSAGE_Execute ()


Entered MESSAGE_Delete ()

Assertion failed (addr != NULL). File : /home/vadmin/OMAP-L138_arm_1_00_00_11/dsplink_linux_1_65_00_02/dsplink/gpp/src/../../gpp/src/ldrv/POOLS/ldrv_pool.c Line : 1037

Unable to handle kernel NULL pointer dereference at virtual address 00000004


pgd = c1ea4000


[00000004] *pgd=c101c031, *pte=00000000, *ppte=00000000


Internal error: Oops: 817 [#1] PREEMPT


last sysfs file: /sys/kernel/uevent_seqnum


Modules linked in: dsplinkk


CPU: 0    Not tainted  (2.6.33-rc4 #1)


PC is at LDRV_MPLIST_getHead+0x1a4/0x1f0 [dsplinkk]


LR is at DA8XXGEM_addrConvert+0xbc/0x144 [dsplinkk]


pc : [<bf0107cc>]    lr : [<bf000698>]    psr: 20000013


sp : c1febdd8  ip : c1febdb8  fp : c1febe04


r10: 00000000  r9 : c2900000  r8 : bf0359f8


r7 : c294d600  r6 : 00000000  r5 : 00000000  r4 : c1febe14


r3 : c296b000  r2 : 00000001  r1 : 00000001  r0 : c3f12600


Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user


Control: 0005317f  Table: c1ea4000  DAC: 00000015


Process msggpp (pid: 861, stack limit = 0xc1fea270)


Stack: (0xc1febdd8 to 0xc1fec000)


bdc0:                                                       c294d700 0020d600


bde0: c1febe04 c294d700 c294d600 00008000 c294d580 00000000 c1febe44 c1febe08


be00: bf00aafc bf010638 bf035698 c1ec9b80 be8a3c64 c2c00080 c1febe34 00000000


be20: 00000001 00000000 c1ec9b80 be8a3c64 c1fea000 40025000 c1febe5c c1febe48


be40: bf00875c bf00a914 0000800d 00000001 c1febe7c c1febe60 bf01fe68 bf0086f0


be60: c018e031 c018e031 be8a3c64 c1ec9b80 c1febeec c1febe80 bf020764 bf01fdd0


be80: c1febe9c c1febe90 c01b0358 c01b02f4 00000000 60000013 c1febf08 c1f5dc00


bea0: c1fea000 0000000c c1fda400 00008000 00000000 be8a3c7c 00008cc0 00009934


bec0: 00021ed0 c01721f4 0000000c c1ec9b80 c018e031 be8a3c64 c1ec9b80 be8a3c64


bee0: c1febf0c c1febef0 c00b37b8 bf020248 00000003 c1ec9b80 00000003 c1ec9b80


bf00: c1febf7c c1febf10 c00b3e7c c00b3744 40990000 00000002 00000000 c1827180


bf20: c1ed5380 0000000c c1fea000 00021edc c1febf6c c1febf40 c00a5d94 c00d52cc


bf40: 00000000 00000000 c002e0a4 00000000 00000000 00000003 be8a3c64 c018e031


bf60: c1ec9b80 c002e0a4 c1fea000 40025000 c1febfa4 c1febf80 c00b3f18 c00b38f8


bf80: c1fea000 00000001 0000035d 00000000 00008c14 00000036 00000000 c1febfa8


bfa0: c002df20 c00b3ee8 0000035d 00000000 00000003 c018e031 be8a3c64 00000003


bfc0: 0000035d 00000000 00008c14 00000036 00000000 00000000 40025000 be8a3c54


bfe0: 00000000 be8a3b40 0000c720 40101aec 80000010 00000003 c04aa031 c04aa431


Backtrace:


[<bf010628>] (LDRV_MPLIST_getHead+0x0/0x1f0 [dsplinkk]) from [<bf00aafc>] (ZCPYMQT_close+0x1f8/0x354 [dsplinkk])


 r8:00000000 r7:c294d580 r6:00008000 r5:c294d600 r4:c294d700


[<bf00a904>] (ZCPYMQT_close+0x0/0x354 [dsplinkk]) from [<bf00875c>] (LDRV_MSGQ_transportClose+0x7c/0xe4 [dsplinkk])


[<bf0086e0>] (LDRV_MSGQ_transportClose+0x0/0xe4 [dsplinkk]) from [<bf01fe68>] (PMGR_MSGQ_transportClose+0xa8/0xf0 [dsplinkk])


 r5:00000001 r4:0000800d


[<bf01fdc0>] (PMGR_MSGQ_transportClose+0x0/0xf0 [dsplinkk]) from [<bf020764>] (DRV_Ioctl+0x52c/0x7f4 [dsplinkk])


 r7:c1ec9b80 r6:be8a3c64 r5:c018e031 r4:c018e031


[<bf020238>] (DRV_Ioctl+0x0/0x7f4 [dsplinkk]) from [<c00b37b8>] (vfs_ioctl+0x84/0xb4)


 r8:be8a3c64 r7:c1ec9b80 r6:be8a3c64 r5:c018e031 r4:c1ec9b80


[<c00b3734>] (vfs_ioctl+0x0/0xb4) from [<c00b3e7c>] (do_vfs_ioctl+0x594/0x5f0)


 r7:c1ec9b80 r6:00000003 r5:c1ec9b80 r4:00000003


[<c00b38e8>] (do_vfs_ioctl+0x0/0x5f0) from [<c00b3f18>] (sys_ioctl+0x40/0x64)


[<c00b3ed8>] (sys_ioctl+0x0/0x64) from [<c002df20>] (ret_fast_syscall+0x0/0x28)


 r7:00000036 r6:00008c14 r5:00000000 r4:0000035d


Code: e1a00005 ebffbe6c e1a04804 e1840820 (e5860004)


---[ end trace 59188382e69cfb96 ]---

  • 0
    TI__Expert 4930 points

    The crash says:

    ZCPYMQT_dpc->LDRV_MPLIST_getHead->Unable to handle kernel NULL pointer dereference at virtual address 00000004

    Some background:

    1)         DSP adds an element to fmDspList and then sends an interrupt to indicate to GPP that a message has been sent.

    2)         This causes the ZCPYMQT DPC to run. This DPC checks the control structure to see if any msg has come in the shared list “fmDspList”.

    a.         fmDspList is an embedded circular doubly linked list in MSGQ control structure present in shared memory i.e. there is no need for a memory allocation call here. The list->head is an address in shared memory. The list is not created/deleted or made NULL.

     3)        The core dump indicates that temp is NULL i.e. message sent by DSP is NULL

    You need to debug how can that happen?

    The list “fmDspList” head element’s is never made NULL in the code. Hence, my hypothesis is that DSP is causing memory corruption at the shared location where the “fmDspList” lies. You need to continue investigation on why the DSP shared memory address which belongs to DSPLINKMEM get corrupt?  One way could be to print the address of fmDspList in function ZCPYMQT_init (file $(DSPLINK)/gpp/src/ldrv/MQT/Davinci/zcpy_mqt.c) after line 326 and instrument from DSP when the list pointers become NULL.

    Deepali

  • 0 in reply to Deepali Uppal
    Prodigy 200 points

    Deepali,

    Thank you very much.   I called my  function in main() instead of in TSKMESSAGE_execute().  The memory corruption disappeared, and the code works now.  Eventually I want to call it inside TSKMESSAGE_execute() though.  So I will investigate more following your advice.  

    Now I have another unrelated problem.   I want to send a double precision floating point back to GPP.   I define an unsigned long long field in my MSGQ message.   Let y be the floating point number.    msg->x = *(unsigned long long*)&y  (in DSP).    I print x out in GPP, but it is not correct.  The first 4  bytes are the  last 4 bytes of y, the last 4 bytes are zero.   For example, it should be 40091EB851EB851F, but the display is 51EB851F00000000.   I tried msg->x = *(unsigned long long*)&y in CCS; it should work.  

    Thanks,

    Kevin

     

    Deepali Uppal said:
    The crash says:
    ZCPYMQT_dpc->LDRV_MPLIST_getHead->Unable to handle kernel NULL pointer dereference at virtual address 00000004

    Some background:

    1)         DSP adds an element to fmDspList and then sends an interrupt to indicate to GPP that a message has been sent.
    2)         This causes the ZCPYMQT DPC to run. This DPC checks the control structure to see if any msg has come in the shared list “fmDspList”.
    a.         fmDspList is an embedded circular doubly linked list in MSGQ control structure present in shared memory i.e. there is no need for a memory allocation call here. The list->head is an address in shared memory. The list is not created/deleted or made NULL.
     3)        The core dump indicates that temp is NULL i.e. message sent by DSP is NULL
    You need to debug how can that happen?
    The list “fmDspList” head element’s is never made NULL in the code. Hence, my hypothesis is that DSP is causing memory corruption at the shared location where the “fmDspList” lies. You need to continue investigation on why the DSP shared memory address which belongs to DSPLINKMEM get corrupt?  One way could be to print the address of fmDspList in function ZCPYMQT_init (file $(DSPLINK)/gpp/src/ldrv/MQT/Davinci/zcpy_mqt.c) after line 326 and instrument from DSP when the list pointers become NULL.
    Deepali

     

     

  • 0 in reply to Deepali Uppal
    Prodigy 200 points

    I increased the task stack size a little bit.  Now the original problem disappeared..