• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 100 subscribers
  • Views 824 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.

Original question:

AM5728: L3 custom errors when starting DSPs

AM5728: L3 custom error when starting DSP

Peter Smith48
Intellectual 310 points

Part Number: AM5728
Other Parts Discussed in Thread: SYSBIOS

I'm seeing the following error on boot on the AM5728 IDK

"L3 Custom Error: MASTER DSP2_DMA TARGET L4_PER3_P3 (Idle): Data Access in User mode during Functional access"

when starting DSP2 on the AM5728 IDK.

Only seems to happen when the DSP's have been stopped via unbind and the board rebooted.

I have read the related question but there seems to be no solution.

Is there any advice on how to stop and restart  the DSP's from Linux?

  • 0
    TI__Guru**** 393215 points

    This has been assigned to a TI engineer, but please note that response may be delayed due to holidays in the USA.

  • 0 in reply to Biser Gatchev-XID
    TI__Guru*** 125430 points

    Hi Peter,

    Does this only happen with the "reboot" command, i.e. if you power cycle the board do you get similar behavior?

    The "Master" you show above is DSP2_DMA.  That's slightly different from the thread you referenced from earlier where the master was DSP2_MDMA.  Both of these relate to the DSP subsystem (i.e. including the associated EDMA instances).  DSP2_MDMA refers to the 66x DSP core itself accessing memory while DSP2_DMA relates to the EDMA accessing memory.  I expect that should be a fairly big clue, i.e. what peripherals or memory are you accessing with the EDMA?

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    Intellectual 310 points

    Thanks for the reply. To be honest I don't know what peripherals I am accessing. To repeat the issue I use the examples provided by TI in the following Yocto recipes (which I add into our custom distribution as shown):

    RDEPENDS_${PN} = " \
    ti-ipc-rtos-fw \
    ti-ipc-examples-linux \
    "

    and on the A15's I am using the following two examples:

    /usr/bin/ipc/examples/ex02_messageq/debug/app_host DSP1

    /usr/bin/ipc/examples/ex02_messageq/debug/app_host DSP2

    The binaries are loaded into the DSP on boot and app_host can be executed as many times as possible. The problem occurs when I unload the binaries (using "unbind" or the other "stop" method) before issuing a reboot. I get thousands of the errors and sometimes the IDK locks up, other times I end up at the login prompt after about 30 seconds. A power cycle recovers the situation. So far it seems as if a power cycle does not cause the problem.

  • 0 in reply to Peter Smith48
    TI__Guru*** 125430 points

    Peter,

    Thanks for the explanation.  I misunderstood your initial post.  I thought the reboot was related to creating the issue.  Now I understand, i.e. the reboot is how you recover.

    Do you have steps for how I can reproduce this same issue?

    Are you using TI's kernel or are you using something from kernel.org, etc.?

    I'm assuming you've made some config changes too.  Have you tried using your kernel config in a TI SDK environment to see if that relates to the issue?

    Best regards,
    Brad

  • 0 in reply to Brad Griffis
    Intellectual 310 points

    Brad,

    That's not quite correct. What happens is, board powers up after power cycle, DSP1 and DSP2 are loaded with the example and code is started running on them, the A15 examples above are then executed and then I stop both DSP's using the "unbind" method and issue reboot from the prompt (this might for example happen when we do a software update as part of the close down and restart process). On restart without a power cycle the errors start appearing during the kernel boot sequence. We have also seen this behavior when we use our product software i.e. not the examples but I don't have access to that at present.

    Its as if the DSP's (or something associated with them) has not been cleanly shutdown.

    Is this the correct way to shut them down or is there something else we should do?

    To answer the other questions, this is a custom Linux Yocto distribution i.e. not based on the TI SDK but it does use TI's RT 4.14 kernel (via the meta-ti layer at commit 9debfc6155ac97050cb85833515ef2617919d6de).

    The device tree is that supplied by the layer for the AM5728 IDK and is unaltered.

    There are kernel configuration additions mainly for hardening, security and Linux containers.

    I have not tried the same kernel configurations with the SDK as of yet.

    Peter

  • 0 in reply to Peter Smith48
    TI__Guru*** 125430 points

    Which DSP executable is being loaded when you perform the reboot?

    Which DSP executable are you testing at run-time?

    I'm trying to understand whitch executables are loaded, whether you're dynamically changing them, and when you are doing the changes.

  • 0 in reply to Brad Griffis
    Intellectual 310 points

    Brad,

    I don't change the DSP binaries at any time. I have created the following links in our root file system

    ln -s /usr/bin/ipc/examples/ex02_messageq/debug/server_dsp1.xe66 /lib/firmware/dra7-dsp1-fw.xe66
    ln -s /usr/bin/ipc/examples/ex02_messageq/debug/server_dsp2.xe66 /lib/firmware/dra7-dsp2-fw.xe66
    ln -s /usr/bin/ipc/examples/ex02_messageq/debug/server_ipu1.xem4 /lib/firmware/dra7-ipu1-fw.xem4
    ln -s /usr/bin/ipc/examples/ex02_messageq/debug/server_ipu2.xem4 /lib/firmware/dra7-ipu2-fw.xem4

    As you can see the test is performed using the ex02_message example software.

    On the Linux side I run these

    /usr/bin/ipc/examples/ex02_messageq/debug/app_host DSP1

    /usr/bin/ipc/examples/ex02_messageq/debug/app_host DSP2

    Peter

  • 0 in reply to Peter Smith48
    TI__Guru*** 125430 points

    Peter,

    Thanks for that additional info.  I have those same files available using the binaries from the TI SDK.  I have reproduced your issue.  I will follow-up with more info later.

    Best regards,
    Brad

  • 0 in reply to Peter Smith48
    TI__Guru*** 125430 points

    Peter,

    The root of the issue was that timerId was not being specified and so DSP2 was attempting to access the wrong timer and was causing an L3 error.  It is an easy one line correction to the Dsp2.cfg file to fix the issue:

    /* --------------------------- TICK --------------------------------------*/
    var Clock = xdc.useModule('ti.sysbios.knl.Clock');
    Clock.tickSource = Clock.TickSource_USER;

    var Timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');

    /* Skip the Timer frequency verification check. Need to remove this later */
    Timer.checkFrequency = false;

    /* Match this to the SYS_CLK frequency sourcing the dmTimers.
    * Not needed once the SYS/BIOS family settings is updated. */
    Timer.intFreq.hi = 0;
    Timer.intFreq.lo = 19200000;

    var timerParams = new Timer.Params();
    timerParams.period = Clock.tickPeriod;
    timerParams.periodType = Timer.PeriodType_MICROSECS;
    /* Switch off Software Reset to make the below settings effective */
    timerParams.tiocpCfg.softreset = 0x0;
    /* Smart-idle wake-up-capable mode */
    timerParams.tiocpCfg.idlemode = 0x3;
    /* Wake-up generation for Overflow */
    timerParams.twer.ovf_wup_ena = 0x1;

    /* Configure BIOS clock source as GPTimer6 */
    Clock.timerId = 5;

    Timer.create(Clock.timerId, Clock.doTick, timerParams);

    I have filed this as a bug (PLSDK-2929) to have it corrected in the next release.  Thanks for reporting this issue.