Forums

Mike,

After offering you some apologies and comments, we will get this thread moved to the BIOS forum for what may be a SYS/BIOS detail. If you get moved back here later, I will stay with you and help where I can. It has been a long day, so please bear with my attitude, below, which is not directed toward you.

I do not not know where you are in the world or how old you are, but in the 1980's in the USA there was a sitcom on TV called Newhart. Three characters in the show were always introduced by "Hi, I'm Larry. This is my brother Darryl, and this is my other brother Darryl." This is relevant to your situation.

Inside each C66x CorePac is the C66x DSP core, plus local L1/L2 memories, plus some special control and logic modules. The C66x DSP core can only accept 16 interrupts, and 4 of those are hard-coded for certain functions, leave only 12 user-controlled interrupt inputs. There are many more than 12 possible interrupt sources, even just within the CorePac itself. So one of the special modules is the internal Interrupt Controller (INTC). This internal INTC accepts 124 events and selects among those 124 events or even combinations of those 124 events, and then generates 12 possible interrupt sources to the C66x DSP core.

Some of the event inputs to the internal INTC come from within the CorePac, such as the "PMC memory protection fault event", number 121. Some of the event inputs to the internal INTC come from outside the CorePac but inside the C6678, such as TINT8L "Timer [8] interrupt low", number 66. In SPRS691a starting on page 146, Table 7-39 "TMS320C6678 System Event Mapping - C66x CorePac Primary Interrupts" lists the 128 events that are the selectable interrupt sources for a CorePac. Each CorePac has one of these internal INTC's. This is what you programmed in SYS/BIOS, and that is why it is limited to 128.

But 128 is not enough. There are many more events that get generated by peripherals and pins and modules in the C6678 from outside the CorePacs. More than 40 events are generated by the combination of the three EDMA3 modules; more than 16 come from the SRIO.

To allow for many more events to be routed through, ultimately to one of a C66x DSP's 12 user interrupts, we added device-level Interrupt Controllers (INTC), or "my other brother Darryl". The device INTC accepts how ever many interrupt sources the device design engineer decided were needed. INTC0 and INTC1 have 160 events numbered, although some are Reserved.

In SPRS691a on page 149, Tables 7-39 through 7-42 lists the events that can be selected by the device INTCs. Those events (or combination of events) are then forwarded to each of the CorePacs and to the internal INTC in a CorePac.

I am sorry that our documentation uses the exact same name for two different modules in the same device. We solved this in the C6474 by calling the internal one the INTC and the device one the Chip Interrupt Controller (CIC). It looks like we forgot some goods ideas from the past. My apologies, because I felt your same confusion as I was reading through the documents trying to figure this out.

I do not know how to program the device INTCs in SYS/BIOS, so we can hope that someone in the BIOS forum can answer that for you. Or they may say you have to run some other package like the MCSDK, in which case you might have your thread moved again.

Regards,
RandyP

Good explanation of why I get this error.  I still would like to know how I can take advantage of SYSBIOS and use the "other brother Darryl" to set up this interrupt.  thanks Mike 

Mike,

Can you please provide a code snippet of how you're configuring your interrupt?

Alan

Alan,

Not to speak out-of-turn for Mike, but I think he was trying to configure the interrupts using the SYS/BIOS tools. He found that the SYS/BIOS INTC configuration is for the CorePac INTC.

How should he configure the device-level INTC with SYS/BIOS?

Regards,
RandyP

Mike,

There is a module called ti.sysbios.family.c66.tci66xx.CpIntc which will allow you to configure this.  I have included a very simple example of configuring this.

In this example, I'm mapping System interrupt 15 to Host interrupt 8.  Then I'm configuraing Hwi 4 with Host interrupt 8.  CpIntc_getEventId() API with the latest 6.32.04 release is correct but has a bug in earlier 6.32 releases.

    CpIntc_mapSysIntToHostInt(0, 15, 8);
    CpIntc_dispatchPlug(15, &event15Fxn, 15, TRUE);
    CpIntc_enableHostInt(0, 8);
    eventId = CpIntc_getEventId(8);

    Hwi_Params_init(&params);
    params.arg = 8;
    params.eventId = eventId;
    params.enableInt = TRUE;
    Hwi_create(4, &CpIntc_dispatch, &params, NULL);

Judah

I will try this later on, I was hoping there was a way using the SYSBIOS gui.  Mike

Okay, I have my code below.  I am trying to create a interrupt with a receive event from the UART Receive. I think this should be event# 149.  'myrxint' is the interrupt routine.   So I map a system interrupt to 149.  Does it matter which system interrupt I use?  In the example you sent me it looks like #15.  What else do I need here to get this interrupt working?  Mike 

Hwi_Params params;

int eventId;

CpIntc_mapSysIntToHostInt(0, 15, 149);

CpIntc_dispatchPlug(15, &myrxint, 15, TRUE);

CpIntc_enableHostInt(0, 149);

eventId = CpIntc_getEventId(149);

Hwi_Params_init(&params);

params.arg = 149;

params.eventId = eventId;

params.enableInt = TRUE;

Hwi_create(4, &CpIntc_dispatch, &params, NULL);

Hwi_enableInterrupt(4);

BIOS_start()

Mike,

michael burke79518

Okay, I have my code below.  I am trying to create a interrupt with a receive event from the UART Receive. I think this should be event# 149.  'myrxint' is the interrupt routine.   So I map a system interrupt to 149.  Does it matter which system interrupt I use?  In the example you sent me it looks like #15.  What else do I need here to get this interrupt working?  Mike 

 

 

Hwi_Params params;

int eventId;

CpIntc_mapSysIntToHostInt(0, 15, 149);

CpIntc_dispatchPlug(15, &myrxint, 15, TRUE);

CpIntc_enableHostInt(0, 149);

eventId = CpIntc_getEventId(149);

Hwi_Params_init(&params);

params.arg = 149;

params.eventId = eventId;

params.enableInt = TRUE;

Hwi_create(4, &CpIntc_dispatch, &params, NULL);

Hwi_enableInterrupt(4);

BIOS_start()

You've got your system/host interrupts backwards.  149 is your system interrupt (This is defined by the hardware, you can't change this).

Now, you need to choose a host interrupt to use.  This is important depending on which core you want to receive this interrupt. I'll post the table here for you conveniece:

The left most number is the GEM event. Inside the array, the numbers corresponds to the host event for core0 or core4, core1 or core5, core2 or core6, core3 or core7 respectively. The array with only 1 number are broadcast events, these are received by all cores using the same CPINTC.                 

                    21: [32, 43, 54, 65],
                    22: [33, 44, 55, 66],
                    23: [34, 45, 56, 67],
                    24: [35, 46, 57, 68],
                    25: [36, 47, 58, 69],
                    26: [37, 48, 59, 70],
                    27: [38, 49, 60, 71],
                    28: [39, 50, 61, 72],
                    29: [40, 51, 62, 73],
                    30: [41, 52, 63, 74],
                    31: [42, 53, 64, 75],
                    62: [2, 10, 18, 26],
                    63: [3, 11, 19, 27],
                    92: [4, 12, 20, 28],
                    93: [5, 13, 21, 29],
                    94: [6, 14, 22, 30],
                    95: [7, 15, 23, 31],
                    102: [0],
                    103: [1],
                    104: [8],
                    105: [9],
                    106: [16],
                    107: [17],
                    108: [24],
                    109: [25],

Assuming you are core0 and you want to receive this system interrupt.  You would do the following:

    CpIntc_mapSysIntToHostInt(0, 149, 32);                 // I picked host int 32 for CPINTC #0.  CPINTC #1 is for cores 4-7
    CpIntc_dispatchPlug(149, &myrxint, arg, TRUE);   //  the 'arg' parameter could be anything, doesn't have to be 149
    CpIntc_enableHostInt(0, 32);                                     // CPINT #0 is for cores 0-3, CPINTC #1 is for cores 4-7
    eventId = CpIntc_getEventId(32);                               // this should return the GEM event 21 (This was a bug fixed in 6.32.04)

    Hwi_Params_init(&params);
    params.arg = 32;                                       // required to be the host interrupt #
    params.eventId = eventId;
    params.enableInt = TRUE;
    Hwi_create(4, &CpIntc_dispatch, &params, NULL); // create ISR to handle this event in Hwi vector 4

Okay, I think that should do it.

Judah

Okay, I think I'm almost there.  However the UART RX interrupt is actually not one of the 127 system events. Its listed as INTC0 event inputs (secondary interrupts) in table 7-32 of sprs691.  Is what you have in the code above still apply or do I have to add something to link the secondary event INTC0 (#149) to one of the primary events?

Judah,

I am trying to enable the UART interrupts also.

I am using the TMDXEVM6678L eval board using MCSDK 2_00_05_17/PDK C6678_1_0_0_17.

the API must be different than what your example uses

CpIntc_mapSysIntToHostInt, CpIntc_dispatchPlug, etc do not exist in my enviornment

is there an example of what API's I should use to map and enable the UART interrupt?

thanks

lwmcgl

Lyndon,

What environment are you in?  What version of BIOS are you using?

If it makes sense to open up a new thread for you problem, I would recommend doing so since this one is marked "answered" already.

Judah

Judah,

windows XP

BIOS 6_32_05_54

this thread is fine since it's the same basic question

thanks,

lwmcgl

Lyndon,

I assumed that you followed the thread and things still don't make sense?

If you are using SYSBIOS then CpIntc API's do exists for you.  They are located at:
     ti/sysbios/family/c66/tci6xx/CpIntc

If you follow the thread, I think what you need to do is find out which INTC interrupt is associated with the UART.
In BIOS terminology this is called the "system interrupt".  Then you need to map the "system interrupt" to a "host interrupt".
You need to pick the "host interrrupt" appropriately (there's a table that I posted) because some host interrupt only interrupt to some cores.
Then you need to map the "host interrupt" to a GEM interrupt

            GEM id: [Host interrupt # core 0 & 4, Host interrupt # core 1 & 5, Host interrupt # core 2 & 6, Host interrupt # core 3 & 7 ]
                    21: [32, 43, 54, 65],
                    22: [33, 44, 55, 66],
                    23: [34, 45, 56, 67],
                    24: [35, 46, 57, 68],
                    25: [36, 47, 58, 69],
                    26: [37, 48, 59, 70],
                    27: [38, 49, 60, 71],
                    28: [39, 50, 61, 72],
                    29: [40, 51, 62, 73],
                    30: [41, 52, 63, 74],
                    31: [42, 53, 64, 75],
                    62: [2, 10, 18, 26],
                    63: [3, 11, 19, 27],
                    92: [4, 12, 20, 28],
                    93: [5, 13, 21, 29],
                    94: [6, 14, 22, 30],
                    95: [7, 15, 23, 31],
                    102: [0],
                    103: [1],
                    104: [8],
                    105: [9],
                    106: [16],
                    107: [17],
                    108: [24],
                    109: [25],

The first number is the GEM event.  The items in the array are the host interrupts #.
The first element in array corresponds to core0 (INTC0) and core4 (INTC1)
The second element in array for core 1 and core 5....etc
Those with only one element means they go to all cores.

The last thing is to create a Hwi for the GEM event.

Judah

Judah,

are the CpIntc API's calls used in a .cfg file or in a regular code .c file?

I don't have the CpIntc folder:

I added the PDK CSL library to the linker file search path thinking the CpIntc API was there.

I see functions like “CSL_CPINTC_mapSystemIntrToChannel” in the PDK CSL,

but didn’t know if these are the equivalent function that you used in your example?

thanks again,

lwmcgl