• Resolved

Linux/66AK2G12: Unable to set LPSC for peripherals used by DSP

Part Number: 66AK2G12

Tool/software: Linux


I am using Processor SDK with CCSv7.3.0.  The various component versions are those that came with that release.

I have modified the MCASP example project to use the hardware configuration on my custom K2G board.  I merged this project with an IPC example so that I could get the DSP running at the same time as Linux, and it does do that.  The catch is that I must manually enable the LPSC in charge of the McASP.  My procedure goes something like this:

- Power up system, let Linux boot.
- Get audio clocks running and IIS routed around the board
- Launch target config and connect DSP
- Load DSP GEL, enable all PSC
- resume processor
- use mpmcl to reset, load, and run the DSP.

This works some of the time.  Sometimes the McASP gets stuck transmitting a single buffer (as though the processor has been halted), or I get an Event Combiner error saying that the event I have connected to the DSP through the CIC (DSP Event 64) is "unplugged".  Sometimes CCS just crashes when I try to connect the processor.  The event combiner error happens whenever I try to restart the program using mpmcl, i.e. if the program was running and I reset and reloaded it.

I encountered similar behavior when I was developing this project using the OMAP-L138.  That post is located here: https://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/612298?tisearch=e2e-sitesearch&keymatch=%20user:301823

How would I go about setting up the LPSC in Linux for the DSP to use?  I would like for Linux to do all of the chip level configuration.  I have:

- Enabled McASP0 in the device tree
- Added reserved slot ranges in the device tree (  ti,edma-reserved-slot-ranges = <24 2>, <128 48>;  )

Any ideas of where to look/what to do to make these two coexist on this platform?


  • Hi Jeff,

    I suggest first to verify with CCS (no OS) that your DSP firmware is working as you intended.

    The approach for enabling PSC for 66AK2G12 upon linux bootup should be similar. Of course you should respect the 66AK2G12 clock structure (you can use the Clock Tree Tool for this: www.ti.com/.../clocktreetool). Then after loading the dsp firmware with mpmcl it should be able to operate with every peripheral that linux enabled, you shouldn't have to use CCS to enable anything manually.

    Maybe you have some dts setting worng. Can you attach your dts?

    Best Regards,


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:


    I have verified its function without Linux running.  I have to leave the pinmux settings and SOC setup code in place for it to work by itself (as is expected).  If I leave this code in place, it breaks Linux when run side-by-side, also not surprising.  The function I am referring to is "configureAudio()" located in audio_evmInit.c.  It is hard, however, to set it up by itself because the ARM is in control of most of the PCB level configuration.  That said, I have made it work.  

    Attached are the DTS files.  Where lines are commented out, it can be assumed that I have tried both with and without the commented sections.


    As always, thank you for your help.


  • In reply to Jeffrey Limbocker:

    Hello Yordan,
    I was wondering if you have had a chance to look this over and if you have any new input.

  • In reply to Jeffrey Limbocker:

    Hi Jeff,

    I am very sorry for the delay. I've missed the e-mail notification.

    I had a look at your dts files and they are correct. Nothing suspicious there.
    I just have one suggestion to test. Can you add full mcasp configuration (as used in your dsp app) with the following definitions inserted in your keystone-k2g-evm.dts:
    op-mode // if applicable to your use case

    This is to check if linux will fully configure your mcasp module on boot up and from then on you will let the dsp application to control it.

    Also I forgot to ask the bootlog, to see exactly what the Combiner error reports. Can you share it?

    Best Regards,


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:


    I have confirmed that the configuration is working via the following process:

    1. Power on board with Linux
    2. Use Linux to configure board
    3. Use CCS debugger to do system reset
    4. Use GEL to release reset on DSP
    5. Use GEL to initialize SOC clocks
    6. Use CCS to load program
    7. Run program

    This is the same program that is loaded using mpmcl in Linux.

    Next, I tried this:

    1. Power on board with Linux
    2. Use Linux to configure board
    3. Use CCS and GEL to turn all LPSC on
    4. Reset dsp using mpmcl
    5. Load dsp using mpmcl
    6. Run program

    This resulted in no output.

    Then I added the following to my DTS:

    op-mode = <0>;
    serial-dir = <
      2 2 2 2
      2 2 2 2
      1 1 1 1
      1 1 1 1 >;
    tx-num-evt = <1>;
    rx-num-evt = <1>;
    assigned-clocks = <&k2g_clks K2G_DEV_MCASP0 K2G_DEV_MCASP_VBUS_CLK>;
    assigned-clock-parents = <&k2g_clks K2G_DEV_MCASP0 K2G_DEV_MCASP_AUX_CLK_PARENT_SYS_OSCCLK>;

    and I followed the steps above with the same results.  Finally, I built the McASP driver into the Linux kernel, and followed the previous steps with zero results.  Even with the McASP driver built into the kernel, the LPSC is still showing that it is not enabled.

    For all three of these test cases, if I used the debugger to enable the PSCs and load the program, the system functions as it should.  It appears to only fail when being loaded with mpmcl.  

    The Event Combiner error is on the RTOS side of things, and so it only shows up on the DSP trace.  There is no new dmesg output when the error occurs.  This error only occurs if the program is re-loaded and re-started after a "successful" run (i.e. it makes past the McASP priming).  It looks like this:

    [t=0x00039b1a] ti.sysbios.family.c64p.EventCombiner: ERROR: line 229: E_unpluggedEvent: Event# 64 is unplugged
    ti.sysbios.family.c64p.EventCombiner: line 229: E_unpluggedEvent: Event# 64 is unplugged
    xdc.runtime.Error.raise: terminating execution
    [t=0x00044023] ti.sysbios.gates.GateMutex: ERROR: line 99: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
    ti.sysbios.gates.GateMutex: line 99: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
    xdc.runtime.Error.raise: terminating execution

    Event 64 is the CIC event I have the rx mux out event routed to.  The source where this is set is configMcasp_SocHwInfo.

    Thank you again for your help.


  • In reply to Jeffrey Limbocker:

    Another finding, though I have not done testing to see how reproducible it is.

    I started and ran the DSP application using CCS with Linux running and the following appeared on dmesg:

    [ 1127.828312] irq 47: nobody cared (try booting with the "irqpoll" option)     
    [ 1127.835343] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O    4.9.59-g8
    [ 1127.844083] Hardware name: Keystone                                          
    [ 1127.847733] Backtrace:                                                       
    [ 1127.850324] [<c020b220>] (dump_backtrace) from [<c020b4dc>] (show_stack+0x18)
    [ 1127.858251]  r7:0000002f r6:200e0193 r5:00000000 r4:c1017728                 
    [ 1127.864182] [<c020b4c4>] (show_stack) from [<c04b901c>] (dump_stack+0x8c/0xa)
    [ 1127.871750] [<c04b8f90>] (dump_stack) from [<c0272158>] (__report_bad_irq+0x)
    [ 1127.879855]  r7:0000002f r6:c1003438 r5:00000000 r4:ef0e9a00                 
    [ 1127.885785] [<c0272128>] (__report_bad_irq) from [<c0272570>] (note_interrup)
    [ 1127.894438]  r9:c1000000 r8:ef008000 r7:0000002f r6:c1003438 r5:00000000 r4:0
    [ 1127.902548] [<c02722dc>] (note_interrupt) from [<c026f800>] (handle_irq_even)
    [ 1127.911652]  r10:c10030ac r9:c1000000 r8:ef008000 r7:00000000 r6:c1003438 r50
    [ 1127.919844]  r4:00000000 r3:00000000                                         
    [ 1127.923592] [<c026f7ac>] (handle_irq_event_percpu) from [<c026f84c>] (handle)
    [ 1127.932875]  r5:ef0e9a60 r4:ef0e9a00                                         
    [ 1127.936624] [<c026f80c>] (handle_irq_event) from [<c0272ef8>] (handle_fasteo)
    [ 1127.945544]  r7:00000000 r6:c1003438 r5:ef0e9a60 r4:ef0e9a00                 
    [ 1127.951473] [<c0272e38>] (handle_fasteoi_irq) from [<c026e964>] (generic_han)
    [ 1127.960485]  r7:00000000 r6:00000000 r5:0000002f r4:c0e4fde0                 
    [ 1127.966413] [<c026e938>] (generic_handle_irq) from [<c026eed8>] (__handle_do)
    [ 1127.975519] [<c026ee74>] (__handle_domain_irq) from [<c0201408>] (gic_handle)
    [ 1127.984259]  r9:c1000000 r8:f0803000 r7:f0802000 r6:c1001ef0 r5:f080200c r4:8
    [ 1127.992366] [<c02013c8>] (gic_handle_irq) from [<c020c078>] (__irq_svc+0x58/)
    [ 1128.000195] Exception stack(0xc1001ef0 to 0xc1001f38)                        
    [ 1128.005482] 1ee0:                                     00000001 00000000 00000
    [ 1128.014042] 1f00: c1000000 c100303c 00000001 c10030a4 00000000 00000000 c100c
    [ 1128.022599] 1f20: c1001f50 c1001f40 c0208688 c020868c 600e0013 ffffffff      
    [ 1128.029524]  r9:c1000000 r8:00000000 r7:c1001f24 r6:ffffffff r5:600e0013 r4:c
    [ 1128.037636] [<c020864c>] (arch_cpu_idle) from [<c087d6ac>] (default_idle_cal)
    [ 1128.046108] [<c087d684>] (default_idle_call) from [<c025e56c>] (cpu_startup_)
    [ 1128.055126] [<c025e3b8>] (cpu_startup_entry) from [<c08789e4>] (rest_init+0x)
    [ 1128.063227]  r7:ffffffff                                                     
    [ 1128.065890] [<c0878958>] (rest_init) from [<c0e00d7c>] (start_kernel+0x3dc/0)
    [ 1128.073718]  r5:00000001 r4:c104104c                                         
    [ 1128.077466] [<c0e009a0>] (start_kernel) from [<80008090>] (0x80008090)       
    [ 1128.084293] handlers:                                                        
    [ 1128.086675] [<c054fac8>] dma_irq_handler                                     
    [ 1128.090787] Disabling IRQ #47  

  • In reply to Jeffrey Limbocker:

    That interrupt number is the same as is used in configMcASP_SocHwInfo
  • In reply to Jeffrey Limbocker:

    Hi Jeff,

    Apologies for the delayed reply. Let us have a look at this.

    Best Regards,


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    Hi Jeff,

    I checked linux sources (all keystone related dts & dtsi files), and I couldn't see IRQ 47 being used...
    Is it possible that the interrupts you use in your DSP app are never enabled in the CIC? Have a look at the CIC enable registers.

    Best Regards,


     Please make sure you read the forum guidelines first.

  • In reply to Yordan Kovachev:

    I will check this. If the interrupts were not being enabled, wouldn't the application fail to work in all cases?
    From first examination, the MAP registers appear to be set correctly. I'll have to dig into the enable registers some.

    Another finding:
    The Event combiner error mentioned above appears when the DSP loses audio signal as well.