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.

Linux/AM5728: Exception being thrown in Linux when manually triggering a GPIO interrupt in TI-RTOS running on DSP1

Part Number: AM5728


Tool/software: Linux

Hi Pavel,
Your suggestion to fix the problem in the post worked for me. Thanks very much.
I configured GPIO2 similarly. I then configured GPIO2_2 as input and am triggering a software interrupt using
GPIOTriggerPinInt(GPIO_BASE_ADDR, 0, GPIO_LED_PIN);
GPIO_BASE_ADDR = (0x48055000U)
GPIO_LED_PIN = 0x02

I get the following on the Linux console:
[ 408.989728] ------------[ cut here ]------------
[ 408.994379] WARNING: CPU: 0 PID: 0 at /opt/PHYTEC_BSPs/yocto_ti/build/arago-tmp-external-linaro-toolchain/work-shared/am57xx-phycore-rdk/kernel-source/drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x25c/0x368()
[ 409.013582] 44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
[ 409.025715] Modules linked in: rpmsg_proto bc_example(O) sha512_generic sha512_arm sha1_generic sha1_arm_neon sha1_arm md5 cbc sha256_generic sha256_arm hmac drbg xfrm_user xfrm4_tunnel ipcomp xfrm_ipcomp esp4 ah4 bluetooth af_key xfrm_algo virtio_rpmsg_bus pruss_intc snd_soc_omap_hdmi_audio omap_wdt omap_aes_driver pru_rproc pvrsrvkm(O) pruss omap_sham ti_vpe dwc3_omap ti_sc ti_vpdma extcon rtc_omap rtc_palmas omap_rng omap_des rng_core omap_remoteproc remoteproc virtio virtio_ring sch_fq_codel gdbserverproxy(O) cryptodev(O) cmemk(O)
[ 409.073659] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W O 4.4.12 #8
[ 409.080823] Hardware name: Generic DRA74X (Flattened Device Tree)
[ 409.086938] Backtrace:
[ 409.089412] [<c00130a4>] (dump_backtrace) from [<c00132a0>] (show_stack+0x18/0x1c)
[ 409.097011] r7:c02e2d18 r6:200f0193 r5:00000000 r4:c09d318c
[ 409.102736] [<c0013288>] (show_stack) from [<c02b6aa8>] (dump_stack+0x90/0xa4)
[ 409.109998] [<c02b6a18>] (dump_stack) from [<c003387c>] (warn_slowpath_common+0x88/0xb8)
[ 409.118121] r7:c02e2d18 r6:00000093 r5:00000009 r4:c09b5d30
[ 409.123845] [<c00337f4>] (warn_slowpath_common) from [<c00338e4>] (warn_slowpath_fmt+0x38/0x40)
[ 409.132578] r8:00000017 r7:c08af0a4 r6:00000000 r5:c08aec6c r4:c08aed10
[ 409.139354] [<c00338b0>] (warn_slowpath_fmt) from [<c02e2d18>] (l3_interrupt_handler+0x25c/0x368)
[ 409.148261] r3:ee1b6140 r2:c08aed10
[ 409.151862] r4:80080003
[ 409.154419] [<c02e2abc>] (l3_interrupt_handler) from [<c0077b30>] (handle_irq_event_percpu+0xb4/0x160)
[ 409.163763] r10:c0a02d2d r9:ee1b0480 r8:00000017 r7:00000000 r6:00000000 r5:ee1b04e0
[ 409.171666] r4:ee1b6640
[ 409.174219] [<c0077a7c>] (handle_irq_event_percpu) from [<c0077c1c>] (handle_irq_event+0x40/0x64)
[ 409.183126] r10:c09b64d0 r9:c06e91e4 r8:ee008000 r7:00000000 r6:c09bc08c r5:ee1b04e0
[ 409.191027] r4:ee1b0480
[ 409.193581] [<c0077bdc>] (handle_irq_event) from [<c007af54>] (handle_fasteoi_irq+0xc0/0x194)
[ 409.202139] r7:00000000 r6:c09bc08c r5:ee1b04e0 r4:ee1b0480
[ 409.207856] [<c007ae94>] (handle_fasteoi_irq) from [<c007715c>] (generic_handle_irq+0x2c/0x3c)
[ 409.216502] r7:00000000 r6:00000000 r5:00000017 r4:c09b0424
[ 409.222221] [<c0077130>] (generic_handle_irq) from [<c0077434>] (__handle_domain_irq+0x64/0xbc)
[ 409.230961] [<c00773d0>] (__handle_domain_irq) from [<c000948c>] (gic_handle_irq+0x40/0x7c)
[ 409.239344] r9:c06e91e4 r8:fa213000 r7:fa212000 r6:c09b5ef0 r5:fa21200c r4:c09b6868
[ 409.247166] [<c000944c>] (gic_handle_irq) from [<c0013d80>] (__irq_svc+0x40/0x74)
[ 409.254678] Exception stack(0xc09b5ef0 to 0xc09b5f38)
[ 409.259750] 5ee0: 00000001 00000000 fe600000 00000000
[ 409.267963] 5f00: c09b4000 c09b6484 00000000 00000000 c09b5f60 c06e91e4 c09b64d0 c09b5f4c
[ 409.276177] 5f20: c09b5f2c c09b5f40 c00268f4 c0010540 600f0013 ffffffff
[ 409.282816] r9:c06e91e4 r8:c09b5f60 r7:c09b5f24 r6:ffffffff r5:600f0013 r4:c0010540
[ 409.290640] [<c0010518>] (arch_cpu_idle) from [<c006d8d8>] (default_idle_call+0x28/0x34)
[ 409.298769] [<c006d8b0>] (default_idle_call) from [<c006db3c>] (cpu_startup_entry+0x204/0x264)
[ 409.307419] [<c006d938>] (cpu_startup_entry) from [<c06df500>] (rest_init+0x90/0x94)
[ 409.315192] r7:00000000
[ 409.317747] [<c06df470>] (rest_init) from [<c095dd88>] (start_kernel+0x400/0x40c)
[ 409.325259] r5:c0a05000 r4:c0a05040
[ 409.328866] [<c095d988>] (start_kernel) from [<80008090>] (0x80008090)
[ 409.335420] ---[ end trace c5f33a20b59aa006 ]---

I can configure the same I/O as an output and it works well.
I have configured that DSP1 IRQ crossbar as follows
*(CTRL_CORE_DSP1_IRQ_56_57) &= ~(DSP1_IRQ_56);
*(CTRL_CORE_DSP1_IRQ_56_57) |= ENABLE_GPIO2_INT_VECTOR;

#define ENABLE_GPIO2_INT_VECTOR 0x00000019
#define DSP1_IRQ_56 0x000001FF

Also I am using the following APIs to enable the interrupt
/* Set the callback function */
GPIO_setCallback(USER_LED0, AppGpioCallbackFxn);

/* Enable GPIO interrupt on the specific gpio pin */
GPIO_enableInt(USER_LED0);

USER_LED0 corresponds to gpio2_2

Any suggestions?

Thanks very much.

Regards,
Shaunak

  • Hi Shaunak,

    I see you have an L3 Custom error, which causes the kernel to panic:
    [ 409.013582] 44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER1_P3 (Idle): Data Access in User mode during Functional access
    In the past, we've managed to resolve similar problems by removing the rtc device tree nodes from the device dts files (abot .dts & the corresponding .dtsi files).

    Can you test this, if your system does not use the RTC?

    Best Regards,
    Yordan
  • Hi Yordan,

    I tried disabling all the RTC instances in the dts and dtsi files but the result is the same.

    Please can you suggest an alternative?

    Regards,

    Shaunak