SRIO doorbell interrupt cannot be trigger

It looks good to me.  Are you seeing the RIO_DoorBell0_ICSR bit 0 getting set, but are not getting the interrupt?  Or is that bit not being set at all?  The thing you have to remember about the INTDST0-15, is that you must write to the pacing register or you will never receive an interrupt. INTDST 16-23 do not require this, so no need to write any pacing register.

Regards,

Travis

Hi,Travis:

Thanks! I follow your advice and I enable interrupt pacing for INTDST0 and set interrupt rate = 10.

Meanwhile,I set Doorbell0_ICSR[0] =1 before every transfer from producer to consumer.Unluckily,

Consumer still cannot receive interrrupt from producer.I don't know the value of interrupt rate which

I set is wright or wrong.I try some values ,either 10 or 1 all cannot enter interrupt too.So,please correct

me .

Below is my modified code from consumer and producer.

producer :

    pConfig = (CSL_SrioRegs*)(0x02900000);
    CSL_SRIO_EnableInterruptPacing (pConfig, 0);    //enable interrupt pacing for INTDST0
    CSL_SRIO_SetInterruptPacing (pConfig, 0, 0x00000001);  //set interrupt rate for INTDST0
    pConfig->DOORBELL_ICSR_ICCR[0].RIO_DOORBELL_ICSR = 0x00000001;   //set Doorbell0_ICSR[0] = 1

consumer:

pConfig = (CSL_SrioRegs*)(0x02900000);
    CSL_SRIO_EnableInterruptPacing (pConfig, 0);
    CSL_SRIO_SetInterruptPacing (pConfig, 0, 0x00000001);
    pConfig->DOORBELL_ICSR_ICCR[0].RIO_DOORBELL_ICSR = 0x00000001;

Hi,Travis:

Another thing,Where can I find an example like what I describe above or would you

provide me that example to show that how producer set and trigger doorbell interrupt

to notify receiver and how consumer bind the doorbell interrupt .

If without example,I am afraid that I misunderstand what you suggest to me.

A couple of threads that may help:

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/132181.aspx

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/196593.aspx - this one has a customer example project.

steve zhang said:

Thanks! I follow your advice and I enable interrupt pacing for INTDST0 and set interrupt rate = 10.

Meanwhile,I set Doorbell0_ICSR[0] =1 before every transfer from producer to consumer.

The value on of pacing register is really irrelevant, you can write 0x0 to the pacing and as long as a doorbell is received, the interrupt should fire if configured correctly.  If you have any concerns there, I'd suggest to use INTDST 16-23, where it is not needed at all.  More importantly, you should never set Doorbell0_ICSR[0] =1 manually.  The ICSR bits are set by incoming Doorbell packets.  Please read the Interrupt section of the SRIO user's guide to understand the operation.  Once set, an ICSR bit has to be cleared by the local core in order for a new interrupt to be created on the RX device.  If it is not cleared and a new doorbell comes in that sets the same ICSR bit, the RX device will send a doorbell retry to the TX device.

Can you dump the following:

Consumer: the Doorbell_ICSR, Doorbell_ICCR,

Producer: LSU completion code after you send the doorbell

Regards,

Travis

Hi,Travis:

Thank you very much for your reply.

I will check those registers what you provide.But I can promise that data

has been arrived at consumer.I can see that data is avaliable from consumer.

Does it mean that you don't see any unsuitable configuration for my source code ?

Why I cannot use INTDST0 ?  I know that you suggest me to use INTDST16-23.But

I think there are still other questions which are unexpected for me If I use INTDST16-23. 

Should I set interrupt  rate on producer and consumer ? I don't know about that .

I also try on both sides .I also try set interrupt pacing register to 0x00.But all failed.

I'll see if I can find an example within TI to show you how to do the doorbell, in the meantime, you can try the customer on one the thread above. 

steve zhang said:

But I can promise that data

has been arrived at consumer.I can see that data is avaliable from consumer.

I understand the data packets are arriving, that is a good sign, and means most of the configuration is good, but you still may have something in the configuration wrong on the consumer side to route interrupts properly.  That is why I asked if the ICSR bit gets set on the consumer side when a doorbell is sent by the producer and what the LSU completion code is on the producer side.  It is very possible that the doorbell is received correctly and sets the ICSR bit correctly, but the interrupt is routed correctly at the chip level to the DSP core.

steve zhang said:

Why I cannot use INTDST0 ?  I know that you suggest me to use INTDST16-23.But

I think there are still other questions which are unexpected for me If I use INTDST16-23. 

You can, it is up to you.  I was just suggesting INTDST 16-23 if you don't want to mess with the pacing.

steve zhang said:

Should I set interrupt  rate on producer and consumer ? I don't know about that .

I also try on both sides .I also try set interrupt pacing register to 0x00.

If you use INTDST 0-15, for any interrupts on producer (LSU completion interrupt),  or consumer (doorbell ICSR interrupt), then you need to write the pacing register that corrresponds to the INTDST you are using.  If you don't, you will not get an interrupt.

Another question.

For what reason ,SRIO_TputBenchmarkingTestProject doesn't support interrupt mode.

I can see that there are some codes about interrupt setup,but someone(including you Travis) from e2e tell me

or tell other people who want to use interrupt mode for that example that sorry,that example cannot

support interrupt mode but only poll mode.

I think SRIO_TputBenchmarkingTestProject is good start for people who learn SRIO.But without

supporting interrupt mode makes that unperfect.

Hi,Travis:

1.

I will try INTDST16-23 as you suggest.

2.

Can TI update Tput example so that it supports interrupt mode and provide for me?

thanks!

Hi,Travis:

I guess my issue comes from two sides.The first side is that consumer cannot receive doorbell packet from producer after producer success to send data to consumer and so ISR cannot be fire.The other side is interrupt configuration issue which means that since consumer receiver doorbell from producer but ISR still cannot be fire because of interrupt configuration issue.

So, I do some experiments to check the fact.

1.

Can consumer receive doorbell from producer?

I do two tests one by one.First I map Doorbell reg0 and bit0 to INTDST0,Second I map doorbell reg0 and bit0 to INTDST16.When producer succeed to send data packet and consumer see that data is available,I view the some registers of SRIO like below:

INTDST0

You can see that doorbell[0].ICSR = 0x0000 0001 and RIO_INTDST_DECODE[0] = 0x0000 0001.Can I consider it that consumer has receive the doorbell packet from producer after data is available ?

INTDST16

Doorbell[0].ICSR = 0x0000 0001. RIO_INTDST_DECODE[16] = 0x0000 0001.

Likely, Does it mean that consumer have receive doorbell from producer?

I think it means. So,I think consumer have succeeded to receiver doorbell from producer.

2.

Is it interrupt configuration issue?

My source code with regarding to interrupt configuration have been proved in past example .

My interrupt configuration code is ported from

pdk_C6678_1_1_2_5\packages\ti\csl\example\cpintc .

Among these examples I have also succeed fire interrupt without any problem.So,I think

Interrupt configuration is good and no problem.

So, above all,Can you give me some advice ?  As to tx LSU completion code ,I can dump,Since once I wait for LSU completion code on producer.it return 1. That means that Transaction Timeout occurred on Non-posted transaction.

steve zhang said:

1.

Can consumer receive doorbell from producer?

I do two tests one by one.First I map Doorbell reg0 and bit0 to INTDST0,Second I map doorbell reg0 and bit0 to INTDST16.When producer succeed to send data packet and consumer see that data is available,I view the some registers of SRIO like below:

INTDST0

You can see that doorbell[0].ICSR = 0x0000 0001 and RIO_INTDST_DECODE[0] = 0x0000 0001.Can I consider it that consumer has receive the doorbell packet from producer after data is available ?

Yes, that is correct as long as you didn't manually write the ICSR bit locally on the consumer as you indicated earlier in the thread.  This is good.  The doorbell is reaching the consumer and setting the interrupt bit. Since you are using INTDST0, the RIO_INTDST0_RATE_CNTL register must be written for the interrupt to fire outside of the peripheral.  The pacing register needs to be written each and every time the interrupt needs to fire, so write it during intialization before any packets are sent, and then also every time the interrrupt ICSR bit is cleared so the next interrupt can fire.

steve zhang said:

INTDST16

Doorbell[0].ICSR = 0x0000 0001. RIO_INTDST_DECODE[16] = 0x0000 0001.

Likely, Does it mean that consumer have receive doorbell from producer?

 

I think it means. So,I think consumer have succeeded to receiver doorbell from producer.

Yes, same as above, except there is no need to write the pacing register.

steve zhang said:

2.

Is it interrupt configuration issue?

My source code with regarding to interrupt configuration have been proved in past example .

My interrupt configuration code is ported from

pdk_C6678_1_1_2_5\packages\ti\csl\example\cpintc .

Among these examples I have also succeed fire interrupt without any problem.So,I think

Interrupt configuration is good and no problem.

If the ICSR bit is set and you the core is not being interrupted, it is definitely an interrupt routing/configuration issue outside the peripheral.  You can look at this article and gel debug script for help:

http://processors.wiki.ti.com/index.php/Configuring_Interrupts_on_Keystone_Devices

steve zhang said:

As to tx LSU completion code ,I can dump,Since once I wait for LSU completion code on producer.it return 1. That means that Transaction Timeout occurred on Non-posted transaction.

Not sure why you would see a timeout.  So you are saying after you send one data transfer followed by doorbell packet, you are seeing a 0b001 completion code in the RIO_LSU_STAT_REGx register?

Hi,Travis:

I check my SRIO interrupt routing and configuration .I found it seems ok too.

I set interrupt ctl register = 1,map doorbell reg0 bit0 to INTDST0.

I can trigger INTDST0 manually as below:

((CSL_CPINTC_RegsOvly)CSL_CP_INTC_0_REGS)->STATUS_SET_INDEX_REG = 112;

in meantime ,I have seen that SRIO interrupt ISR can be fired.

But when I don't trigger manually It means that trigger by receiving doorbell interrupt

from producer.ISR still cannot be fired.You know I have verify that ICSR bit has been set.

Meanwhile,I also verify that SRIO interrupt routing and configuration is correct because

I can trigger SRIO 112 system event by manually .what's the matter?

Does it matter that I use DSPC-8681E from advantech?If I use two 6678EVM connecting

 with BOC.Can I avoid this strange stiuation?

card.

It is not clear to me how you are manually triggering the Event 112.  Here is what I'd suggest use the INTDST 16 and use the primary interrupt (Event 20) to the core instead of the CIC event (Event 112).  So...

CSL_SRIO_SetDoorbellRoute(hSrio, 0);

    for (i = 0; i < 16; i++)

    {

        CSL_SRIO_RouteDoorbellInterrupts(hSrio, 0, i, 0);

    }

then map the event 20 to a vector (based on http://processors.wiki.ti.com/index.php/Configuring_Interrupts_on_Keystone_Devices)  Note that you should probably change the vector from 4 to 9 for example, since 4 is used for other purposes including boot.
...

{
   CSL_IntcObj intcObj;
   CSL_IntcGlobalEnableState state;

   CSL_IntcContext context;

   CSL_Status intStat;
   CSL_IntcParam vectId;

   context.numEvtEntries = 0;
   context.eventhandlerRecord = NULL;

   CSL_intcInit(&context);

   CSL_intcGlobalNmiEnable();
   intStat = CSL_intcGlobalEnable(&state);

   vectId = CSL_INTC_VECTID_9;
   hIntc = CSL_intcOpen (&intcObj, 20, &vectId, NULL);

   EventRecord.handler = &eventHandler;
   EventRecord.arg = hIntc;

   CSL_intcPlugEventHandler(hIntc,&EventRecord);
   CSL_intcHwControl(hIntc,CSL_INTC_CMD_EVTENABLE,NULL);
 
   CSL_IntcClose(hIntc);
}

Hi,Travis:

I follow you advice and try with event 20 with vector id = 9.but still fail.

I have verified that interrupt routing and configuration is no problem.Because I view

the register of INTMUX2 INTSEL9 = 0x14 = 20 which is the right number.

So,I believe interrupt routing and configuration is ok.

Since,I want to ask you how can you make sure doorbell with reg=0 ,bit=0 valid = 1

must trigger INTDST16 event? I cannot see that anyway .How can you prove that with details?

Another,When you set doorbell route like below :

CSL_SRIO_RouteDoorbellInterrupts (hSrio, 0, 0, 0);

Does it mean that you route doorbell reg=0,bit=0 to INTDST0 instead of INTDST16?

When I try with CSL_SRIO_RouteDoorbellInterrupts (hSrio, 0, 0, 16) it still doesn’t work.

Hi,Travis:

As you said,SRIO routing and configuration is no problem.Meanwhile,interrupt routing

and configuration is also ok .Since,Everything is no problem,What's the matter?

Hi Steve,

I'm working on a SRIO doorbell example, but in the meantime you should take a look at the DIO ISR example project included in the MCSDK. It's located at the following location:

<install directory>\pdk_C6678_x_x_x_x\packages\ti\drv\exampleProjects\SRIO_LoopbackDioIsrexampleproject

This example demonstrates usage of interrupts to indicate the end of DIO transfers. The example also uses INTDST0 and sys/bios, which seems to match your use case.

To comment on some of the debug information you have provided, it seems to me that the issue is related to your ISR setup. If you are seeing the bit set in the SRIO DOORBELLn ICSR (as long as you are not doing this manually, as Travis said), the interrupt has made it out of the SRIO peripheral. If your ISR is hooked up properly, it should fire when the ICS0 bit is set.

Please let us know if this example helps and if you have any questions or comments.

Thanks,

Clinton