DSPLink problem

CC46425

Other Parts Discussed in Thread: OMAP3530

Hi,

Starting from TI DSPLink examples (readwrite), I would like to send an image to the dsp-side for compression and then send it back to gpp-side. I first tried without doing any operation on dsp-side, just a loop. I have 2 problems.

1. With a .txt file it's working fine but with image (a small one) , I get an unreadable file !

2. I also changed memory map to use larger files but with a 1Mb image I don't receive any file back from the dsp-side, I get these errors

============= Sample Application : READWRITE ==========
Entered RDWR_Create ()
Leaving RDWR_Create ()
Entered RDWR_Execute ()
Buffer size: 1080054
file size OK
Size of file = 1080054
Unable to handle kernel paging request at virtual address c4b00000
pgd = c2f18000
[c4b00000] *pgd=82fb4011, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1] PREEMPT
Modules linked in: dsplinkk cmemk ipv6 minix
CPU: 0    Not tainted (2.6.32-rc2-davinci1 #1)
PC is at memcpy+0x50/0x330
LR is at 0xdbd6d6d6
pc : [<c0166870>]    lr : [<dbd6d6d6>]    psr: 20000013
sp : c3161da4 ip : d6d6d6de fp : c3161dcc
r10: bf11b168 r9 : 40b09008 r8 : deded5d5
r7 : d5d5d5d5 r6 : dadadad6 r5 : d6d6d8d8 r4 : d8e4e4e4
r3 : e1e1e1d9 r2 : 00057a56 r1 : 40bb9028 r0 : c4b00000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005317f Table: 82f18000 DAC: 00000015
Process waaves_decgpp (pid: 1639, stack limit = 0xc3160270)
Stack: (0xc3161da4 to 0xc3162000)
1da0:          84050000 00000000 00000001 00107af6 c4a50000 40b09008 bf101f14
1dc0: c3161df4 c3161dd0 bf0eed40 bf101f14 00107af6 00000000 84050000 00000001
1de0: 40b09008 00000001 c3161e24 c3161df8 bf0ee260 bf0eec2c 00107af6 40b09008
1e00: 00107af6 00107af6 00000000 bf11b178 00000000 84050000 c3161e5c c3161e28
1e20: bf0f000c bf0ee1e8 40b09008 c3161e38 00000000 00107af6 40b09008 00000000
1e40: 84050000 be9d5b9c c3160000 40025000 c3161e84 c3161e60 bf107248 bf0eff38
1e60: 40b09008 c3161eb4 00006c0c c3161eb4 00008000 be9d5b9c c3161eec c3161e88
1e80: bf109670 bf1071e8 c00888b0 c0074b64 c0029c00 00000000 00000200 c31a9ac0
1ea0: 00000000 0000006a 400b0000 c0494ec0 40023000 00008000 00000000 84050000
1ec0: 00107af6 40b09008 00107af6 c3161ed8 c2f4fa00 be9d5b9c 00006c0c c2f4fa00
1ee0: c3161f0c c3161ef0 c00aafa4 bf1091c4 c310e8a8 c2f4fa00 00000003 c2f4fa00
1f00: c3161f7c c3161f10 c00ab630 c00aaf3c c3161f34 c3161f20 c016ca88 c003acf4
1f20: 00000200 c208a700 c3161f44 c3161f38 c005cd94 c016c9e0 c3161f7c c3161f48
1f40: c0032780 c005cd94 c016c9a8 c003acf4 c3161f7c 00000003 be9d5b9c 00006c0c
1f60: c2f4fa00 c002d044 c3160000 40025000 c3161fa4 c3161f80 c00ab6cc c00ab0c8
1f80: ffffffff 00000001 00008eac 00000000 00008e00 00000036 00000000 c3161fa8
1fa0: c002cec0 c00ab69c 00008eac 00000000 00000003 00006c0c be9d5b9c 00000003
1fc0: 00008eac 00000000 00008e00 00000036 00000000 00000000 40025000 be9d5b84
1fe0: 00000000 be9d5ab8 0000bb68 40101aec 20000010 00000003 00000000 00000000
Backtrace:
[<bf101f04>] (MEM_Copy+0x0/0x18 [dsplinkk]) from [<bf0eed40>] (DM6467GEM_write+0x124/0x1cc [dsplinkk])
[<bf0eec1c>] (DM6467GEM_write+0x0/0x1cc [dsplinkk]) from [<bf0ee260>] (DSP_write+0x88/0xa8 [dsplinkk])
[<bf0ee1d8>] (DSP_write+0x0/0xa8 [dsplinkk]) from [<bf0f000c>] (LDRV_PROC_write+0xe4/0x180 [dsplinkk])
r8:84050000 r7:00000000 r6:bf11b178 r5:00000000 r4:00107af6
[<bf0eff28>] (LDRV_PROC_write+0x0/0x180 [dsplinkk]) from [<bf107248>] (PMGR_PROC_write+0x70/0xb4 [dsplinkk])
[<bf1071d8>] (PMGR_PROC_write+0x0/0xb4 [dsplinkk]) from [<bf109670>] (DRV_Ioctl+0x4bc/0x850 [dsplinkk])
r7:be9d5b9c r6:00008000 r5:c3161eb4 r4:00006c0c
[<bf1091b4>] (DRV_Ioctl+0x0/0x850 [dsplinkk]) from [<c00aafa4>] (vfs_ioctl+0x78/0x94)
r7:c2f4fa00 r6:00006c0c r5:be9d5b9c r4:c2f4fa00
[<c00aaf2c>] (vfs_ioctl+0x0/0x94) from [<c00ab630>] (do_vfs_ioctl+0x578/0x5d4)
r7:c2f4fa00 r6:00000003 r5:c2f4fa00 r4:c310e8a8
[<c00ab0b8>] (do_vfs_ioctl+0x0/0x5d4) from [<c00ab6cc>] (sys_ioctl+0x40/0x64)
[<c00ab68c>] (sys_ioctl+0x0/0x64) from [<c002cec0>] (ret_fast_syscall+0x0/0x28)
r7:00000036 r6:00008e00 r5:00000000 r4:00008eac
Code: f5d1f05c f5d1f07c e8b151f8 e2522020 (e8a051f8)
---[ end trace 054a240dbad44e88 ]---

I'm using Ubuntu 10.4 and TI MAKE system to build sources using DSPLink, both for GPP and DSP

EVM : DM6467T

CCSv 4.1

DSPLink 1.64

DVSDK 3.1

Windows 7 pro 64 bits

Does anybody have any suggestion ?

Thanks

over 15 years ago

0 Deepali Uppal over 15 years ago

TI__Expert 4930 points

CC,

Did you have a look at http://processors.wiki.ti.com/index.php/Writing_DSPLink_Application_using_PROC_read_and_write_APIs ?

Please go through above link for generic steps on using PROC_read/PROC_write. In you specific crash, I suspect an error in mapping the address that you are trying to write to using PROC_write. Is that memory address correctly mapped to in the memory map?

Deepali

0 CC46425 over 15 years ago in reply to Deepali Uppal

Intellectual 530 points

Deepali,

Thanks for your answer.

I think the memory address is correctly mapped in the memory map, but I'm going to check again.

I opened the image I received from DSP in an hexadecimal editor, and the first 4087 bytes are the same (original image is 225.1 Kb) ???

I tried sending an 2.2 Kb image and it works fine ???

Do you have any explanation to that ?

0 CC46425 over 15 years ago in reply to CC46425

Intellectual 530 points

Deepali,

I changed the read address and now I can send larger files without any problem but i still receive corrupted files from dsp. Datas are ok only for the first 4000 bytes.

0 Deepali Uppal over 15 years ago in reply to CC46425

TI__Expert 4930 points

CC,

Are you doing cache operations on the buffer?

The memory segments are cacheable on the DSP-side. The control for enabling/disabling cache is with the system integrator through DSP/BIOS configuration. DSPLink maintains cache coherence on DSP-side for all its modules control structures, as well as POOL buffers if they are sent using DSPLink modules such as MSGQ (message buffer cache coherence is performed), CHNL (data transfer cache coherence is performed), NOTIFY (payload cache coherence is performed) and RingIO (data and attribute buffer cache coherence is performed). For protocols which use ListMP and PROC_read/PROC_write in the applications, cache coherency of POOL buffers needs to be done by the application.

Deepali

0 CC46425 over 15 years ago in reply to Deepali Uppal

Intellectual 530 points

Deepali,

I'm using readwrite example from TI and I didn't modify it a lot yet, The only cache operations are in the original tskReadwrite.c file

HAL_cacheInv ((Ptr) readBuf, size) ;

HAL_cacheWbInv ((Ptr) writeBuf, size) ;

0 Deepali Uppal over 15 years ago in reply to CC46425

TI__Expert 4930 points

CC,

Has size been updated to reflect the complete data size that you are trying to send?

Deepali

0 CC46425 over 15 years ago in reply to Deepali Uppal

Intellectual 530 points

Deepali,

If you mean size variable in tskReadwrite.c file, I did. The file I receive from the DSP has correct size , the problem is that first 4KB of datas are ok, then datas are wrong and datas at the end of the file are correct ??? I tried to write in different places of the memory and to disable cache, it didn't change anything.

Regards

0 Deepali Uppal over 15 years ago in reply to CC46425

TI__Expert 4930 points

CC,

Does the mem variable in the Linux bootargs correctly reflect the memory map? Have you set the MAR bits for the DSP memory space correctly?

Deepali

0 CC46425 over 15 years ago in reply to Deepali Uppal

Intellectual 530 points

Deepali,

I changed memory map according to TI's tutorial. Changing mem bootarg to 64M worked fine with a 14KB txt file but with an image file, I still have only the first 4087 bytes correct.

0 Deepali Uppal over 15 years ago in reply to CC46425

TI__Expert 4930 points

CC,

From a DSPLink perspective there is no difference between the text file and the image file. If it works for the text file it should work for the image file as well.

Can you share your application so I can have a look at it?

Deepali

0 CC46425 over 15 years ago in reply to Deepali Uppal

Intellectual 530 points

Deepali,

The only difference is the file size, it seems there is a size limitation (about 14kB), It works fine with smaller image. If the file is larger than this limit, the copy is correct roughly only for the 4000 first bytes and then it jumps somewhere at the end of the file and copy it . I checked the datas after PROC_write and it's ok. The problem seems to be on DSP side when the copy takes place.

You'll find my application in attached file.

Appli.zip

0 CC46425 over 15 years ago in reply to CC46425

Intellectual 530 points

Deepali,

I've just found my mistake. I was using readwrite example from TI and in readwrite.c I had erased the /* Prime the DSP memory regions to allow for data integrity check */ part but I had left the PROC_write in DSP memory region (bufIn). Now it's working correctly, Sorry and thanks for you help.

I also posted about a problem about running decode demo on DM6467T (Failed to create display device instance ) and still I don't have any answer.

0 Dave Winder15947 over 14 years ago in reply to Deepali Uppal

Intellectual 485 points

What about the cache coherency on the Arm side of an Omap3530? I dont see any code in the MSGQ module or lower that is doing this.

I also just found:

mapInfo.memAttrs = MEM_UNCACHED ;

in my omap3530_phy_shmem.c file.

I am having problems with a LIST_putTail() call in LDRV_MSGQ_put(). On response messages from the DSP, it works once or twice and then gets a message of gibberish wich causes an abort exception. Trying to debug it with breakpoints will make it behave. I suspect the cache is being updated on the breakpoints.

Im stumped.

0 Deepali Uppal over 14 years ago in reply to Dave Winder15947

TI__Expert 4930 points

Dave,

DSPLink does no cache coherency on ARM side. There are no cache calls on ARM code. The memory is mapped as uncached.

Is this a different sample application than the one you were trying earlier?

Could this be the issue http://processors.wiki.ti.com/index.php/Troubleshooting_DSPLink_configuration_issues#Problem:_I_see_a_crash_as_soon_as_I_run_a_DSPLink_sample.

Deepali

0 Dave Winder15947 over 14 years ago in reply to Deepali Uppal

Intellectual 485 points

Hi Deepali

Different Dave I think.

Anyway , that link is not my problem. Putting more info over at

http://e2e.ti.com/support/dsp/omap_applications_processors/f/447/p/65729/239094.aspx#239094

thanks

Processors

Processors forum

DSPLink problem