• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 579 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.

Video randomly hangs few minutes after starting encode (issue related to silicon errata ?)

LABBE Claire
Prodigy 185 points
Other Parts Discussed in Thread: TVP5146

To summarize the situation, we used a platform based on DM6446 EVM with TVP5146, we have integrated MPEG and H264 encode and resizer.

I finally configured the OSD/VENC to output it to a monitor from an image sensor.

While running the video encoding, few minutes later, the video is frozen and sometimes the system would hang afterwards.

This happens in a random way but always happens after 3 minutes, or 20 minutes or more than after the encoding start...

I suspected something wrong in terms of memories specially either with Davinci or ARM.

 I have checked the CPU, swap. Every thing seems to be fine !

 Note this issue happens for both TMX320DM6446ZWT (Revision 1.1) and TMX320DM6446AZWT (Revision 1.2) and noticed that this problem occurs more often when recording video through the GSTREAMER (ffmpeg) which is I know not a TI product.

 I have carefully read the Silicon errata document (SPRZ241N) .

It seems that I am not concerned with the advisory 2.2.27: VPFE: Preview Engine Hangs When the Video Port is Enabled.

However, I have some doubt with the advisory 1.3.24: ARM: Concurrent Access to ARM Internal Memory May Fail.

How can I check if my problem is related to this advisory.

 Which on-line commands or script shall I run to get such information as I am not very familiar with ARM internal memory.

Not sure if the frozen or hang video problem is related to my video freezing problems…

Any help or suggestions would be grateful appreciated !

 

NOTA BENE:

I am using the Linux 2.6.32 with dvdsk 2.00.00.22 and DM6446 DSP.

I use the frame buffer to display both OSD and video...
davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB
davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 1224KB
davincifb davincifb: dm_osd1_fb: 720x576x4@0,0 with framebuffer size 2025KB
davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 1224KB

For your information, the interested UBoot parameters is as follows:
videostd=pal
bootargs=console=ttyS0,115200n8 root=/dev/mmcblk0p1 rootdelay=4 rw consoleblank=0 mem=108M video=davincifb:osd0=720x576,2025K@0,0:osd1=720x576,2025K davinci_enc_mngr.ch0_mode=pal davinci_enc_mngr.ch0_output=COMPOSITE

  • 0
    Guru 31670 points

    Claire,

    Your problem needs more analysis. Inorder to rule out the Errata advisories you can do the following experiments. 

    1. If you are using preview engine, then disable it or remove the use case.

    2. If you are using ARM IRAM map the buffer to a different memory location. 

    These experiments will clear the doubt. 

    Also, have you connected JTAG and saw the state of ARM? Have you checked the CPSR register state when this happens?

  • 0 in reply to Renjith Thomas
    Prodigy 185 points

    Hi Thomas,

    The preview engine has been disabled.

    I will try to map the ARM IRAM to a different location, and will let you know what's on !

    Unfortunately I am not using the JTAG to see the state of ARM and therefore, don't know the status of CPSR.

    I presume that you mean CPSR like Current Program Status Register, do you ?

    If so, I have to find out a solution to get the status of CSPR register state from the Linux 2.6.32 cross reference, may be through a specific package or a linux command orsomething else.

    I will keep you informed.

  • 0 in reply to LABBE Claire
    Guru 31670 points

    Labbe,

    By CPSR I meant the current program status register of ARM. Without using JTAG it will be tough to get the status register when it fails as you won't be able run anything. So, its better to use CCS and JTAG to understand what's going on.

  • 0 in reply to Renjith Thomas
    Prodigy 185 points

    Concerning the CSPR,

    Since I don't have the CCS and JTAG, I was able to know the CSPR through "info reg" command line in "gdb"

    (gdb) info reg

    r0 0xfffffdfc 4294966780

    r1 0xbea1d6c8 3198277320

    r2 0x0 0

    r3 0x8 8

    r4 0x0 0

    r5 0xbea1d648 3198277192

    r6 0x3fcf8 261368

    r7 0xa2 162

    r8 0xbea1d5c8 3198277064

    r9 0x7fffffff 2147483647

    r10 0xbea1d6c8 3198277320

    r11 0xbea1d53c 3198276924

    r12 0x0 0

    sp 0xbea1d538 0xbea1d538

    lr 0x403d6a78 1077766776

    pc 0x403d6ccc 0x403d6ccc <nanosleep+28>

    fps 0x0 0

    cpsr 0x40000010 1073741840

    However, I have activated some debug option in "Kernel Hacking" of the kernel menu config and found an additional indication:

    The last debug lines I have are:

    Video encoder: h264enc

    Venc InBuf size: 153600

    Venc OutBuf size: 76800

    INFO: task kmmcd:168 blocked for more than 120 seconds.

    "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

    kmmcd         D c0291c4c     0   168      2 0x00000000

    Backtrace:

    [<c0291950>] (schedule+0x0/0x390) from [<c01eab50>] (__mmc_claim_host+0xd0/0x1a0)

    [<c01eaa80>] (__mmc_claim_host+0x0/0x1a0) from [<c01edcd0>] (mmc_sd_detect+0x30/0x78)

    [<c01edca0>] (mmc_sd_detect+0x0/0x78) from [<c01eaf00>] (mmc_rescan+0xa0/0x36c)

    r5:c50ba938 r4:c50ba800

    [<c01eae60>] (mmc_rescan+0x0/0x36c) from [<c004f4e8>] (worker_thread+0x13c/0x200)

    r6:c5084000 r5:c50ba938 r4:c50ba93c

    [<c004f3ac>] (worker_thread+0x0/0x200) from [<c0053258>] (kthread+0x88/0x90)

    [<c00531d0>] (kthread+0x0/0x90) from [<c003ffdc>] (do_exit+0x0/0x694)

    r7:00000000 r6:00000000 r5:00000000 r4:00000000

    Kernel panic - not syncing: hung_task: blocked tasks

    Looking

    Looking in Linux forum for mmc/sd crashed, I found this discussion (http://e2e.ti.com/support/embedded/linux/f/354/p/150986/902830.aspx#902830 )

    Seems to me a kernel Linux problem specially on SDIO, so that I shall update my kernel version (actually I am working with Linux 2.6.32.33)?

    Correct me if not  !

    Have you ever heard some problems concerning the MMC/SD crash ?

     

  • 0 in reply to LABBE Claire
    Guru 31670 points

    Labbe,

    GDB is also another program that's running on the target. Since you are able to execute GDB commands, it means that your CPU is still running and not crashed somewhere. Regarding MMC/SD can you try to disable power management completely in your kernel and see whether it works? 

    Also migrating the kernel might be better but not always guaranteed, because there can be the same or different set of issues in the newer kernel as well. So, if you've spent a lot of effort already on this platform, in my opinion its better to fix the issue and use the existing software stack rather than migrating to a newer kernel and again solving another set of issues. 

    What are you using your SD card for? Is complete file system kept inside the card? If so, can you try to move it to NAND and see the behavior? 

  • 0 in reply to Renjith Thomas
    Prodigy 185 points

    Sorry for my late reply as I was on  holidays last week.

    Concerning the disability of power management in my kernel, I suppose I shall intyeract with "menuconfig" and will let you know.

    Concerning the migration of the kernel, I am still reluctant, as it can araise a set of new issues and I do agree with you that it is not the solution.

    Before I was using San Disk 35 MB/s as SDHC card. As I was suspected something wrong in terms of video streaming, I decide to replace by SanDisk Extreme 95MB/s in which the complete filesystem is kept inside.

    Concerning to you last suggestion, we don't have NAND in our system, only 2 NOR flash, one for uImage flashing , the other which is still not used actually, will be for the emergency boot feature. SO no way to see the behavior through a NAND.

    I will kept you informed by the end of this week.