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.

AM5728: McASP RX DMA events stall

Part Number: AM5728

Hi,

I am trying to get my McASP Receiver to transfer received TDM frames via chip-level EDMA into DSP(1) L2RAM.

I am using McASP2, and have configured the receiver to use internal clock for now with 7 active 24bit timeslots, and a total frame length of 10 timeslots.

The format is set to pad these 24bit slots to 32bit words.

The AFIFO is enabled with RNUMDMA=1 and RNUMEVT=7.

The DMA crossbar is using the default mapping of McASP2 RX to DMA channel 2, and I have PaRAM entry doing A transfer with ACNT=28 (7*4), and BCNT=240.

I find that only 1 ACNT worth of data (28 bytes) get transferred by the EDMA, and then nothing more.

If I manually trigger an EDMA event via the ESR then I get a further ACNT bytes.

I observe that the MCASP seems to still be running based on the RSLOT etc incrementing.

However ROVRN =1.

I also see the below L3 error printed on the Linux side. To me this seems to suggest that the access made by the EDMA to the McASP DATA port is not correct somehow, and then the AFIFO is not getting emptied so no further event is generated.

My PaRAM entry SRC = 0x45C00000.

Could you please advise as to what I could check next?

Many thanks,

James

[   63.854066] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x330/0x380
[   63.863239] 44000000.ocp:L3 Standard Error: MASTER TC1_EDMA TARGET MCASP2 (Write Non-Posted): At Address: 0x00000000 : Opcode Fetch in User mode during Debug access
[   63.877993] Modules linked in: xfrm_user xfrm4_tunnel ipcomp xfrm_ipcomp esp4 ah4 af_key xfrm_algo xhci_plat_hcd xhci_hcd dwc3 udc_core snd_soc_simple_card snd_soc_simple_card_utils snd_soc_omap_hdmi omap_aes_driver ahci_platform libahci_platform libahci omap_sham libata omap_wdt scsi_mod phy_omap_usb2 ti_vip pvrsrvkm(O) ti_vpe ti_sc ti_csc v4l2_fwnode ti_vpdma dwc3_omap rtc_omap c_can_platform c_can can_dev omap_des omap_hdq des_generic crypto_engine omap_crypto wire mt9m111 extcon_palmas rtc_palmas edt_ft5x06 snd_soc_tlv320aic3x omap_rng sch_fq_codel uio_module_drv(O) uio ftdi_sio usbserial usbcore usb_common gdbserverproxy(O) cryptodev(O) cmemk(O)
[   63.936094] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O      4.19.79-g8177f87071 #1
[   63.944568] Hardware name: Generic DRA74X (Flattened Device Tree)
[   63.950687] Backtrace:
[   63.953156] [<c020ca34>] (dump_backtrace) from [<c020cd6c>] (show_stack+0x18/0x1c)
[   63.960762]  r7:c0dfc1a0 r6:60060193 r5:00000000 r4:c124e55c
[   63.966458] [<c020cd54>] (show_stack) from [<c09ff4e0>] (dump_stack+0x90/0xa4)
[   63.973719] [<c09ff450>] (dump_stack) from [<c022e098>] (__warn+0xdc/0xf8)
[   63.980626]  r7:c0dfc1a0 r6:00000009 r5:00000000 r4:c1201cbc
[   63.986315] [<c022dfbc>] (__warn) from [<c022dcdc>] (warn_slowpath_fmt+0x50/0x6c)
[   63.993834]  r9:eea25940 r8:f0883058 r7:c0dfc0c0 r6:c0dfc54c r5:c0dfc170 r4:c1204c48
[   64.001615] [<c022dc90>] (warn_slowpath_fmt) from [<c057ef3c>] (l3_interrupt_handler+0x330/0x380)
[   64.010526]  r3:eea29ac0 r2:c0dfc170
[   64.014117]  r5:00000005 r4:80080001
[   64.017717] [<c057ec0c>] (l3_interrupt_handler) from [<c02895e8>] (__handle_irq_event_percpu+0x68/0x140)
[   64.027242]  r10:c1250178 r9:eea77e00 r8:00000017 r7:c1201de8 r6:00000000 r5:eea77e68
[   64.035104]  r4:eea29f80
[   64.037654] [<c0289580>] (__handle_irq_event_percpu) from [<c02896f4>] (handle_irq_event_percpu+0x34/0x88)
[   64.047352]  r10:c10664f0 r9:c1200000 r8:ee80c000 r7:00000001 r6:eea77e00 r5:eea77e68
[   64.055215]  r4:c1204c48
[   64.057765] [<c02896c0>] (handle_irq_event_percpu) from [<c0289788>] (handle_irq_event+0x40/0x64)
[   64.066677]  r6:c120a434 r5:eea77e68 r4:eea77e00
[   64.071318] [<c0289748>] (handle_irq_event) from [<c028d4d8>] (handle_fasteoi_irq+0xc0/0x168)
[   64.079880]  r7:00000001 r6:c120a434 r5:eea77e68 r4:eea77e00
[   64.085568] [<c028d418>] (handle_fasteoi_irq) from [<c02887e4>] (generic_handle_irq+0x2c/0x3c)
[   64.094218]  r7:00000001 r6:00000000 r5:00000000 r4:c1066cfc
[   64.099906] [<c02887b8>] (generic_handle_irq) from [<c0288e48>] (__handle_domain_irq+0x64/0xbc)
[   64.108647] [<c0288de4>] (__handle_domain_irq) from [<c057d278>] (gic_handle_irq+0x44/0x80)
[   64.117037]  r9:c1200000 r8:fa213000 r7:c1201eb0 r6:fa212000 r5:fa21200c r4:c1205104
[   64.124818] [<c057d234>] (gic_handle_irq) from [<c02019f8>] (__irq_svc+0x58/0x8c)
[   64.132334] Exception stack(0xc1201eb0 to 0xc1201ef8)
[   64.137408] 1ea0:                                     00000000 0001a9b4 eed5750c c0222150
[   64.145622] 1ec0: ffffe000 c1204c7c c1204cc4 00000001 00000000 00000000 c10664f0 c1201f0c
[   64.153837] 1ee0: c1201eec c1201f00 c0221de4 c0208e94 a0060013 ffffffff
[   64.160481]  r9:c1200000 r8:00000000 r7:c1201ee4 r6:ffffffff r5:a0060013 r4:c0208e94
[   64.168266] [<c0208e6c>] (arch_cpu_idle) from [<c0a194cc>] (default_idle_call+0x30/0x34)
[   64.176397] [<c0a1949c>] (default_idle_call) from [<c025a890>] (do_idle+0x204/0x2ac)
[   64.184178] [<c025a68c>] (do_idle) from [<c025ac24>] (cpu_startup_entry+0x20/0x24)
[   64.191783]  r10:c104aa38 r9:c1251c80 r8:ffffffff r7:c1251c80 r6:00000000 r5:00000002
[   64.199646]  r4:000000c7
[   64.202194] [<c025ac04>] (cpu_startup_entry) from [<c0a13774>] (rest_init+0xd0/0xd4)
[   64.209976] [<c0a136a4>] (rest_init) from [<c1000dfc>] (start_kernel+0x448/0x470)
[   64.217491]  r5:00000000 r4:c1251cd8
[   64.221083] [<c10009b4>] (start_kernel) from [<00000000>] (  (null))
[   64.227463] ---[ end trace af1d27d7e3ca095f ]---

  • After a lot of wasted time I eventually found the small note in the TRM:

    McASP1, McASP2, and McASP3, whose data ports are accessible directly via L3_MAIN, do
    not support FIFO/constant addressing modes. Incrementing transfers must be used instead.