66AK2G12: Running separate code for ARM and DSP, DSP interrupts don't fire

Brett Anderson

Part Number: 66AK2G12
Other Parts Discussed in Thread: SYSBIOS

I have a project that uses SYSBIOS on the ARM core to run the NDK. In the DSP, there is completely separate code running. They were developed by separate people and know nothing about each other. No IPC is being used. If I load the ARM code, it runs correctly. If I load the DSP code, it runs correctly. If I load both code at the same time, the ARM code runs correctly, and so does the DSP. The only hangup is that when loaded together, no interrupts are generated on the DSP code, so it can't process. There should be an interrupt from a GPIO that is driving the state machine.

I'm loading them both from SD Card on the k2gevm. The loading works as I expect. (I can attach and both are loaded and running after boot)

I'm using the latest SysBios and processor SDK (6.x, the latest available). Network activity matches exactly what I want. DSP runs, but just sits waiting for interrupts.

Any ideas? What can I look at? If I load the DSP alone, it runs and interrupts work correctly.

Any help appreciated. I know this is a non-standard setup. Beating my head against it. I didn't write the DSP code, but need to figure this out.

over 6 years ago

0 Rahul Prabhu over 6 years ago

TI__Guru** 116960 points

Brett,

That is a bit odd. Generally when merging the ARM and DSP code, we recommend application developers to consolidate the SOC and HW initialization to the core that is the system boot master on which the SBL executes. On K2G as the bootloader runs on the A15, all of the pinmux, clock and other associated SOC initialization should be done on the ARM. Can you please specify what interrupt is not triggering on the DSP. Is it a peripheral interrupt, DMA or any other internal error interrupt like ECC or memory protection? Are you using any event combiner functionality on the DSP to configure the interrupts?

The other thing to check would be the driver SOC configuration and memory utilized by ARM And DSP application. Ensure that there is no memory overlap between the ARM and the DSP applications. Is there a UART or another driver that may be used by both the cores ? The SBL loads and runs the DSP application and then the ARM application. Can you load the DSP application after the ARM application using JTAG and see if you see the same behavior? Another coarse way to debug this would be to dump the Control MMR and interrupt registers for the DSP with or without the ARM application loaded and see if there is a change that could lead to the interrupt not triggering on the DSP.

Regards,

Rahul

0 Brett Anderson over 6 years ago in reply to Rahul Prabhu

Prodigy 110 points

Hi Rahul, Thank you so much for your reply.

The project is to help move existing DSP code to the K2G platform, with the ARM core handling telnet access. Just background.

I have all of the pinmux/clocks and such in the ARM code. In the DSP, they have the vector table located at the beginning of RAM, and they are loading the vectors manually. The one I am trying to track down is a gpio input.

int setups:

    C66x_InterruptController->InterruptMux.C66x_ISR_4 = (uint8_t)C66x_TIMER_1_INTL;
    C66x_InterruptController->InterruptMux.C66x_ISR_5 = (uint8_t)C66x_CIC_0_OUT32;
    C66x_InterruptController->InterruptMux.C66x_ISR_6 = (uint8_t)C66x_GPIOMUX_INT16;

The ISR_6 should be firing based on an input pin.

_intcVectorTable:
_vector0:   VEC_ENTRY _c_int00      ;RESET
_vector1:   VEC_ENTRY _vec_dummy    ;NMI
_vector2:   VEC_ENTRY _vec_dummy    ;RSVD
_vector3:   VEC_ENTRY _vec_dummy    ;RSVD
_vector4:   VEC_ENTRY _timerHeartBeatHandler
_vector5:   VEC_ENTRY _mcASPHandler
_vector6:   VEC_ENTRY _LOOP_controlLoop
_vector7:   VEC_ENTRY _vec_dummy
_vector8:   VEC_ENTRY _vec_dummy
_vector9:   VEC_ENTRY _vec_dummy
_vector10:  VEC_ENTRY _vec_dummy
_vector11:  VEC_ENTRY _vec_dummy
_vector12:  VEC_ENTRY _vec_dummy
_vector13:  VEC_ENTRY _vec_dummy
_vector14:  VEC_ENTRY _vec_dummy
_vector15:  VEC_ENTRY _vec_dummy

The event combiner is not being used. They are using Timer1. Does that conflict with SysBios?

Can you confirm something you said? The SBL loads the DSP first, and then the ARM? So it is probable that the ARM is stepping on the DSP since it gets loaded second.

I'll work through some of this later tonight.

0 Rahul Prabhu over 6 years ago in reply to Brett Anderson

TI__Guru** 116960 points

Brett Anderson said:
Can you confirm something you said? The SBL loads the DSP first, and then the ARM? So it is probable that the ARM is stepping on the DSP since it gets loaded second.

Let me clarify. IF you look at the code sbl_main.c in the sbl package in location pdk_k2g_1_0_xx\packages\ti\boot\sbl\board\evmK2G\sbl_main.c. The combined multicore application image (ARM app + DSP app) is loaded into memory together but the SBL starts running the DSP application before it passes control from SBL to ARM app in the SBL code as you can see from the code below:

The image copy loads both the applications but the DSP application start from entry point will happen prior to MPU (ARM) application start in the SBL code sequence.

TImer used by SYSBIOS:

The timer usage in SYSBIOS Is typically documented in the SYSBIOS package

bios_6_75_02_00\packages\ti\sysbios\timers\dmtimer\doc-files

I beleive that Cortex A15 platforms typically use timer 1 so please check for timer instance conflicting between the two cores in SYSBIOS

Changing timer instance and timer ID used has been described in the USer guide in the following section:

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#how-to-set-input-frequency-in-sysbios-configuration-and-change-timer-used-by-clock-module

Regards,

Rahul

Processors

Processors forum

66AK2G12: Running separate code for ARM and DSP, DSP interrupts don't fire