• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 437 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.

TDA4VM: About the TIDL thread in QNX hangs

Frank DU
Prodigy 190 points
Part Number: TDA4VM
Other Parts Discussed in Thread: SYSBIOS
Hello, TI experts!
We are developing the TDA4 product using QNX+ROTS. The SDK version is 8.2.
In our product, we have observed occasional freezing when using TIDL in long-running scenarios.
The freezing occurs in the TIDL thread within QNX, and it remains stuck in the vxWaitGraph state.
Upon investigation, we found a similar known issue on the TI website: EXT_EP-10713.
sir.ext.ti.com/.../EXT_EP-10713
The conditions for occurrence are as follows:
  • High load on the A72 core (typically exceeding 80%, occasionally even reaching 95%)
  • The issue occurs when running the OD graph
  • Long-running scenarios
We would like to clarify the following points based on the information above:
  1. The TI website mentions registers such as SE0_FAR, SE0_FSR, SE1_FAR, SE1_FSR, IEAR, and IERR. Where can we find detailed explanations of these registers in a document or webpage?
  2. In practical scenarios, how can we dump or print the information from these registers on the C71? Our actual runtime environment does not allow direct connections via network cards or serial ports,so can we output  the register infomation to local files or to the log system?
  3. Regarding the statement in EXT_EP-10713's description “We found an issue with idle task stack overflowing, so we disabled preemptive interrupts and increased the idle task stack,” what should we do on the source code?
    1. Does “disabled preemptive interrupts” mean making the DISABLE_INTERRUPTS_DURING_PROCESS macro effective?
    2. Does “increase idle task stack” refer to increasing the size of gTarget_tskStack in source/platform/psdk_j7/rtos/tivx_target_config_c7.c?
Thank you for your assistance!
  • 0
    TI__Mastermind 24041 points

    Hi,

    Due to limited bandwidth am unable to look into this thread at the moment.

    I will try to circle back in 1 week.

    Thank you for your patience.

  • 0 in reply to Pratik Kedar
    TI__Guru 50253 points

    Hi Frank,

    We found several issues resulting from the debug in that issue logs.

    First issues was:

    In previous SDK versions, we were seeing stack overflow happening occasionally. Newer SDK versions have the fix integrated. You could check if the following is in c7x_1.cfg:

    1. Disable auto nesting. This didnt help solve, but the stack overflow occurred much earlier than before.

    var HwiC7x = xdc.useModule('ti.sysbios.family.c7x.Hwi');
    HwiC7x.bootToNonSecure = true;
    HwiC7x.dispatcherAutoNestingSupport = false;

    2. Increase IDLE task stack size from 16KB to 64KB.

    var Task = xdc.useModule('ti.sysbios.knl.Task');
    Task.idleTaskStackSize = 64 * 1024;

    Second issue was:

    We root caused the issue to be that on the customer board, we were using a pre-production silicon that has not undergone full TMS program testing. So we were seeing some devices behave in unexpected ways sometimes when the full silicon capability is stressed.

    Third issue and workaround was:

    When we lowered DDR speed from 4266MT/s to 3733MT/s, we saw some improvements with behaviors for some boards (aka, some boards stopped hanging and passed long duration testing).

    You could check/try these out to see if one of these issues was causing hangs.

    Regards,

    Takuma

  • 0 in reply to Takuma Fujiwara
    Prodigy 190 points
    Thank you for the detailed reply. We will confirm it in our product.
    There was another question in the previous issue that was not mentioned clearly, which is:
    "
    The TI website mentions registers such as SE0_FAR, SE0_FSR, SE1_FAR, SE1_FSR, IEAR, and IERR. Where can we find detailed explanations of these registers in a document or webpage?
    In practical scenarios, how can we dump or print the information from these registers on the C71? Our actual runtime environment does not allow direct connections via network cards or serial ports, so can we output the register information to local files or to the log system?
    "
    We look forward to the professional answers from experts. Thank you.
  • 0 in reply to Frank DU
    TI__Guru 50253 points

    Hi Frank,

    C7x register descriptions are NDA restricted material. There are a couple of E2E from a few years back that request access like this: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/871565/tda4vm-c7000-hardware-guide-and-mma-programming-guide.

    Of public documentations, section 1.1 of this documentation mentions related C7x materials: https://www.ti.com/lit/ug/spruig6k/spruig6k.pdf. Specifically, "C71x DSP CPU, Instruction Set, and Matrix Multiply Accelerator (SPRUIP0, which is available through your TI Field Application Engineer)" has IEAR, IERR descriptions, and C71x DSP Corepac Technical Reference Manual - SPRUIQ3 has FAR, FSR register descriptions.

    During debug for the issue linked in your original post, we were using a TI EVM that has access to JTAG and onboard XDS110 debugger.

    As a start, I think troubleshooting based on my previous post would be the simpler and easier route. If troubleshooting does not work and we see different behaviors, then a more in-depth debug would make sense in which we may want to dump these C7x registers.

    Regards,

    Takuma