• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 101 subscribers
  • Views 176 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

PROCESSOR-SDK-DRA7X: Task not run normally

Woj
Prodigy 235 points
Part Number: PROCESSOR-SDK-DRA7X
Other Parts Discussed in Thread: SYSBIOS

Hello,

To load PDK McASP example image into IPU1 from kenel remote proc module, I added IPC to the example project according to http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/How_to_Guides.html#create-dsp-and-ipu-firmware-using-pdk-drivers-and-ipc-to-load-from-arm-linux-on-am57xx-devices.

There are two tasks in the new project, one is Audio_echo_Task created by mcasp, and another is smain created by ipc. The problems are:

1. According to the remote proc log, there is only one task, which is the one with lower priority, has been scheduled to run.

2. Not any log output from the running task.

3. The task seems not return to run after calling Task_sleep. I guess this maybe caused by the reason that there is not a valiable tick, and I don't have any idea that why the online document ask to "Comment out the entire TICK section". Morover, the result is same even I add the TICK confiuration.

Environment:

DRA762 custom board(NOT a TI EVM)

bios_6_52_00_12 + ipc_3_47_01_00 + pdk_dra7xx_1_0_10

configuration file: /cfs-file/__key/communityserver-discussions-components-files/791/loopback_5F00_m4.cfg

log: /cfs-file/__key/communityserver-discussions-components-files/791/MCASP_5F00_Audio_5F00_evmDRA72x_5F00_m4ExampleProject_5F00_with_5F00_ipc_2D00_timer_2D00_disabled.txt

  • 0
    TI__Expert 5725 points

    Hi Woj,

    From your log, it looks like all of your tasks are scheduled to run (ready hook runs when tasks become available to run).  Though, it is not clear what task is actually running in the print

    [0][ 0.000] mySwitch: ignoring dummy 1st prev Task

    What task is this and what is happening inside?

    The tick section in the config file you have provided would be needed to configure a custom tick function.  You don't need that since BIOS will by default have an OS tick function in the Clock module.  I'm not sure why the article referenced describes this, but in general your case should be okay with the default timer configuration.

    Have you been able to confirm the IPC example applications to work properly on your platform?

    Is this also the 6AO.1.1 + Vision SDK platform, or is it something different (trying to understand you listing DRA7xx PDK above)?  If something different, what is the OS/version you are running on A15?

    Thanks,
    Stephen

  • 0 in reply to Stephen Molfetta
    Prodigy 235 points

    Hello Stephen,

    Sorry for late reply.

    Stephen Molfetta said:
    What task is this and what is happening inside?

    One is smain, which is created by the ex02_messageq. Another is Audio_echo_Task, which is created by McASP example. For more details, please refer to the source code: /cfs-file/__key/communityserver-discussions-components-files/791/MCASP_5F00_Audio_5F00_evmDRA72x_5F00_m4ExampleProject_5F00_with_5F00_ipc.7z

    Stephen Molfetta said:
    Have you been able to confirm the IPC example applications to work properly on your platform?

    Is it a must to confirm the IPC example first of all? I mean, the reason of adding the IPC example to the McASP example is that I need the McASP example to be loaded into M4 core from the kernel remote proc module. In other words, I don't care whether the IPC example can communicate with other cores or not at all.

    Stephen Molfetta said:
    Is this also the 6AO.1.1 + Vision SDK platform, or is it something different (trying to understand you listing DRA7xx PDK above)?  If something different, what is the OS/version you are running on A15?

    Yes, it is also the 6AO.1.1 + Vision SDK platform, except that the pdk_dra7xx_1_0_10, from which the McASP example created, I used is installed by the ti-processor-sdk-rtos-automotive-dra7xx-evm-04.03.00.05.

  • 0 in reply to Woj
    TI__Expert 5725 points

    Hi Woj,

    Woj said:
    Is it a must to confirm the IPC example first of all?

    It's not mandatory, but this is a good starting point for sanity check.  Sometimes it is helpful to take what is known/working and start from there.  I say this because I had not seen the steps you mentioned from the developer doc which were introduced in a later version of the Processor SDK, so I have not tested myself to know whether there is anything missing when approaching from this way.

    Woj said:
    Yes, it is also the 6AO.1.1 + Vision SDK platform, except that the pdk_dra7xx_1_0_10, from which the McASP example created, I used is installed by the ti-processor-sdk-rtos-automotive-dra7xx-evm-04.03.00.05

    The only difference here and the setup you mention from https://e2e.ti.com/support/processors/f/791/p/864177/3222780 is just a swap of the driver library from BSP to PDK?  Did you have the same application setup and load through remoteproc/IPC?  If so, I encourage to instead use that working configuration and just link the new McASP driver library.  You should not need Board, I2C, and UART libraries assuming that your Linux kernel is doing platform setup correctly.

    I'm looking at the code and see your while(1) with MCASP_log and Task_sleep.  I assume MCASP_log is the issue behind "Not any log output from the running task" from the original thread.  What macro does this map to?  Is this System_printf, UART, or some other print handler?

    The Task_sleep in this while loop is where you claim to be stuck?  Do you know what the state of the CPU is at this time?  Do you have the ability to debug via JTAG to see?

    The only other strange thing I see is you setting Timer TIOCP IDLEMODE to 0x1.  TRM mentions this is for debug mode only.  In any case, you shouldn't need to do this, but I don't see how this affects the timer from triggering properly.  You can set a breakpoint in ti_sysbios_knl_Clock_doTick__I to confirm whether the ISR is run.

    Thanks,
    Stephen