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.

RTOS/AM5728: McASP issue on IPU2

Part Number: AM5728

Tool/software: TI-RTOS

Hi,

I made MCASP1 working perfectly onto DSP1 but now I need it to work onto IPU2.

I remapped all registers accordingly so that MCASP1 binding/creating/setuping is all good.

But, the DMA transfer doesn't seem to work at all, although I have a good incoming frame sync and bit clock.

Is it possible to make MCASP1 working onto IPU1 ?

I saw into the TRM that IPU2 might be reserved strictly for IVA-HD...... is that true ?

Thanks.

  • The RTOS team have been notified. They will respond here.
  • Here is what I am getting whenever I receive my first frame sync event on MCASP1_RX, then nothing else afterwards:

    [ 130.911209] ------------[ cut here ]------------
    [ 130.915870] WARNING: CPU: 0 PID: 19 at /extra4/releases/tbx/TBX-0.9.77.3/common.hg/yocto/ti/build/arago-tmp-external-linaro-toolchain/work-shared/am57xx-cc/kernel-source/drivers/bus/omap_l3_noc.c:148 l3_interrupt_handler+0x25c/0x36c()
    [ 130.936731] 44000000.ocp:L3 Custom Error: MASTER TC2_EDMA TARGET DMM_P2 (Read): Data Access in User mode during Functional access
    [ 130.948429] Modules linked in: cryptodev(O) cmemk(O)
    [ 130.953428] CPU: 0 PID: 19 Comm: irq/23-l3-app-i Tainted: G O 4.4.32-rt41 #1
    [ 130.961639] Hardware name: Generic DRA72X (Flattened Device Tree)
    [ 130.967755] Backtrace:
    [ 130.970230] [<c0012bb4>] (dump_backtrace) from [<c0012db0>] (show_stack+0x18/0x1c)
    [ 130.977829] r7:c02aebe4 r6:00000094 r5:00000009 r4:00000000
    [ 130.983552] [<c0012d98>] (show_stack) from [<c0283174>] (dump_stack+0x24/0x28)
    [ 130.990817] [<c0283150>] (dump_stack) from [<c003d1cc>] (warn_slowpath_common+0x88/0xb4)
    [ 130.998949] [<c003d144>] (warn_slowpath_common) from [<c003d230>] (warn_slowpath_fmt+0x38/0x40)
    [ 131.007682] r8:ef16e550 r7:c06e0184 r6:00000002 r5:c06dfc70 r4:c06dfd14
    [ 131.014456] [<c003d1fc>] (warn_slowpath_fmt) from [<c02aebe4>] (l3_interrupt_handler+0x25c/0x36c)
    [ 131.023363] r3:ef16e3c0 r2:c06dfd14
    [ 131.026964] r4:80080003
    [ 131.029521] [<c02ae988>] (l3_interrupt_handler) from [<c0075f00>] (irq_forced_thread_fn+0x28/0x7c)
    [ 131.038515] r10:00000000 r9:c07f436c r8:c0075ed8 r7:ef162780 r6:00000001 r5:ef162780
    [ 131.046421] r4:ef16e900
    [ 131.048972] [<c0075ed8>] (irq_forced_thread_fn) from [<c00761d4>] (irq_thread+0x100/0x1d8)
    [ 131.057268] r7:ef162780 r6:00000001 r5:ef18a000 r4:ef16e900
    [ 131.062984] [<c00760d4>] (irq_thread) from [<c005763c>] (kthread+0xdc/0xf4)
    [ 131.069972] r9:00000000 r8:00000000 r7:c00760d4 r6:ef16e900 r5:ef16e940 r4:00000000
    [ 131.077793] [<c0057560>] (kthread) from [<c000f970>] (ret_from_fork+0x14/0x24)
    [ 131.085044] r7:00000000 r6:00000000 r5:c0057560 r4:ef16e940
    [ 131.090763] ---[ end trace 0000000000000002 ]---
  • Hi Yves,

    Do you have a standalone CCS McASP RTOS project working on IPUx without Linux running on ARM and loading IPU image from ARM?

    Is the DMA transfer issue only happening with the Linux running on ARM?

    Regards,
    Garrett
  • Well, guys, I cannot remove the A15 from the loop as I use remoteProc to start all DSPs and IPUs....

    But, my main question was only if this is possible or not to do MCASP work onto an IPU ????

    I figured out myself that it can work reliably but sometimes, it just doesn't start and crash....

    I think I can figure out those instability myself because at the end, I saw it working well.

    Thanks anyway but I would have appreciate more a direct answer to my simple question above.

  • Yves,

    The two IPU subsystems are identical from functional point of view, however, running your own firmware on IPU2 is not supported by our teams, see e2e.ti.com/.../586950

    Figure 14-3. Connectivity Matrix in TRM shows 'c' between McASPx and IPUx, which indicates a functional path exists.

    Regards,
    Garrett