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.

CCS/AM5716: with SYSBIOS, during emulation, processor freeze before main()

Part Number: AM5716
Other Parts Discussed in Thread: SYSBIOS

Tool/software: Code Composer Studio

Hello,

I have created a default DSP project in CCS v8.3 (SYS/BIOS-TI Target Examples-Typical) and I would like to emulate the code with my custom board with a Sitara AM5716. On ARM-A15 runs Linux.

When I download the DSP code, it stops in the following while loop (Timer.c):

    /* if doing SOFTRESET: do it first before setting other flags */
    if (obj->tiocpCfg & TIMER_TIOCP_CFG_SOFTRESET_FLAG) {
        timer->tiocpCfg = TIMER_TIOCP_CFG_SOFTRESET_FLAG;
        while (timer->tiocpCfg & TIMER_TIOCP_CFG_SOFTRESET_FLAG)
                ;

and from the debug uart of arm, I get the following messages:

[ 3255.962648] WARNING: CPU: 0 PID: 0 at drivers/bus/omap_l3_noc.c:147 l3_interrupt_handler+0x330/0x380
[ 3255.971910] 44000000.ocp:L3 Custom Error: MASTER DSP1_MDMA TARGET L4_PER3_P3 (Read): Data Access in User mode during Functional access
[ 3255.984110] Modules linked in: xfrm_algo omap_wdt omap_crypto gdbserverproxy(O)
[ 3255.991708] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W  O      4.19.38-g4dae378bbe #1
[ 3256.000253] Hardware name: Generic DRA72X (Flattened Device Tree)
[ 3256.006433] Backtrace:
[ 3256.009028] [<c020ca24>] (dump_backtrace) from [<c020cd5c>] (show_stack+0x18/0x1c)
[ 3256.016721]  r7:c0b928f4 r6:60060193 r5:00000000 r4:c10492ec
[ 3256.022516] [<c020cd44>] (show_stack) from [<c08a6be0>] (dump_stack+0x90/0xa4)
[ 3256.029869] [<c08a6b50>] (dump_stack) from [<c022de60>] (__warn+0xdc/0xf8)
[ 3256.036857]  r7:c0b928f4 r6:00000009 r5:00000000 r4:c1001cbc
[ 3256.042634] [<c022dd84>] (__warn) from [<c022daa4>] (warn_slowpath_fmt+0x50/0x6c)
[ 3256.050244]  r9:ef2067c0 r8:f0880e64 r7:c0b92820 r6:c0b92be8 r5:c0b928c4 r4:c1004c48
[ 3256.058123] [<c022da58>] (warn_slowpath_fmt) from [<c051bd14>] (l3_interrupt_handler+0x330/0x380)
[ 3256.067106]  r3:ef203f40 r2:c0b928c4
[ 3256.070767]  r5:00000002 r4:80080003
[ 3256.074465] [<c051b9e4>] (l3_interrupt_handler) from [<c028861c>] (__handle_irq_event_percpu+0x68/0x140)
[ 3256.084077]  r10:c104aed7 r9:ef205800 r8:00000016 r7:c1001de8 r6:00000000 r5:ef205868
[ 3256.092002]  r4:ef1f4300
[ 3256.094651] [<c02885b4>] (__handle_irq_event_percpu) from [<c0288728>] (handle_irq_event_percpu+0x34/0x88)
[ 3256.104433]  r10:c0e61430 r9:c1000000 r8:ef008000 r7:00000001 r6:ef205800 r5:ef205868
[ 3256.112357]  r4:c1004c48
[ 3256.115003] [<c02886f4>] (handle_irq_event_percpu) from [<c02887bc>] (handle_irq_event+0x40/0x64)
[ 3256.123987]  r6:c1023974 r5:ef205868 r4:ef205800
[ 3256.128720] [<c028877c>] (handle_irq_event) from [<c028c3f4>] (handle_fasteoi_irq+0xc0/0x168)
[ 3256.137358]  r7:00000001 r6:c1023974 r5:ef205868 r4:ef205800
[ 3256.143134] [<c028c334>] (handle_fasteoi_irq) from [<c028782c>] (generic_handle_irq+0x2c/0x3c)
[ 3256.151860]  r7:00000001 r6:00000000 r5:00000000 r4:c0e61bfc
[ 3256.157640] [<c0287800>] (generic_handle_irq) from [<c0287e7c>] (__handle_domain_irq+0x64/0xbc)
[ 3256.166478] [<c0287e18>] (__handle_domain_irq) from [<c051a050>] (gic_handle_irq+0x44/0x80)
[ 3256.174949]  r9:c1000000 r8:fa213000 r7:c1001eb0 r6:fa212000 r5:fa21200c r4:c1005100
[ 3256.182821] [<c051a00c>] (gic_handle_irq) from [<c02019f8>] (__irq_svc+0x58/0x8c)
[ 3256.190406] Exception stack(0xc1001eb0 to 0xc1001ef8)
[ 3256.195556] 1ea0:                                     00000000 00263d40 fe600000 00000000
[ 3256.203850] 1ec0: ffffe000 c1004c7c c1004cc4 00000001 00000000 00000000 c0e61430 c1001f0c
[ 3256.212139] 1ee0: c1001eec c1001f00 c0221cdc c0208e94 60060013 ffffffff
[ 3256.218867]  r9:c1000000 r8:00000000 r7:c1001ee4 r6:ffffffff r5:60060013 r4:c0208e94
[ 3256.226754] [<c0208e6c>] (arch_cpu_idle) from [<c08c0b6c>] (default_idle_call+0x30/0x34)
[ 3256.234978] [<c08c0b3c>] (default_idle_call) from [<c025a198>] (do_idle+0x20c/0x2b4)
[ 3256.242852] [<c0259f8c>] (do_idle) from [<c025a52c>] (cpu_startup_entry+0x20/0x24)
[ 3256.250540]  r10:c0e47a38 r9:c104c9c0 r8:ffffffff r7:c104c9c0 r6:00000000 r5:00000002
[ 3256.258465]  r4:000000c5
[ 3256.261114] [<c025a50c>] (cpu_startup_entry) from [<c08bae54>] (rest_init+0xd0/0xd4)
[ 3256.268998] [<c08bad84>] (rest_init) from [<c0e00dfc>] (start_kernel+0x448/0x470)
[ 3256.276579]  r5:00000000 r4:c104ca18
[ 3256.280247] [<c0e009b4>] (start_kernel) from [<00000000>] (  (null))

I don't really know what to modify to start with main function.

Best regards

Francesco

  • Hi Francesco,

    >>I have created a default DSP project in CCS v8.3 (SYS/BIOS-TI Target Examples-Typical) and I would like to emulate the code with my custom board with a Sitara >>AM5716. On ARM-A15 runs Linux.

    I assume you meant you created a DSP project for C66xx core using SYS/BIOS.

    >>When I download the DSP code, it stops in the following while loop (Timer.c):

    I assume you loaded the DSP binary file (*.OUT) using JTAG to a connected C66x core. If you tried to load the DSP binary file (*.OUT) to A15 core, it will not work, because it runs the Linux.

    The other thing that you should make sure is that in order to connect to C66x core using JTAG, you may have to halt the A15 core first and run GEL file on A15 which may reset the A15 core, therefore break your Linux execution on A15 core.

    Ming

  • Hi Ming,

    you are right, I'm using XDS200 Jtag emulator to download  the DSP binary file (*.out) into DSP C66x inside the SItara AM5716. I follow the procedure in the link to take C66 out of the reset (AM571x_multicore_reset.gel) and simultaneously have A15 working with linux.

    After download the DSP is already runnig, if I suspend the emulation stops like this:

    then if I run and suspend again, it stops:

    Till this point I have many warnings coming from the debug uart of A15.

    After this, my program starts running as I expected.

    I think timer has some conflicts with A15 but I don't know why.

    I don't know If It is clear my problem.

    Francesco

  • Hi Francesco,

    The issue may be related to the DSP accessing the register space of a timer instance Linux has already claimed.  Looking at dra7.dtsi, all 16 timers have been populated.

    Can you try unbinding the associated timer driver on the Linux side, (timer16 used an example below - not sure which timer SYS/BIOS grabs by default).:

    cd /sys/bus/platform/drivers/omap_timer
    echo 4882e000.timer > unbind

    Regards,
    Mike

  • Thank you Mike,

    SYSBIOS seems to use timer5 (48820000.timer). I've tried to write the echo command before the DSP emulation but didn't work. I have to try again but I think this is the right direction.

    regards

    Francesco