OPB write actions

Hi,

I've succesfully build a microblaze system with external interrupt and my
own IP core (using the opb slave template in the EDK). The interrupt is
connected to a dip-switch. In the ISR I'm writing some data to my own IP
core (which is an OPB slave). My OPB slave is reading some other
dip-switches and put the result to some LEDs (yes I'm using an evaluation
board ;). So far everything is ok. Now comes the problem: the expected
behaviour is dependent of the code in the ISR. If I've the following ISR:

void dip_isr(void)
{
 *(opb_mycore_base) = 0x12345678;

 // Write the value of j to the LED
// XGpio_DiscreteWrite(&gp_out, 0);

#ifdef USE_INTC
 XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK);
#endif
}

it's not working. But if I enable the XGpio write, it is working. And at
last, if I do the XGpio write first and than the write to the OPB slave
(opb_mycore) it's again not working anymore. In all three situations, the
code is coming in the ISR (I see that, because there is no output at the
uart anymore, which is done in the main program).

I don't know what is happening. Can anybody help me?!

TIA,
Frank

Hi Frank,

Frank wrote:
> I've succesfully build a microblaze system with external interrupt and my
> own IP core (using the opb slave template in the EDK). The interrupt is
> connected to a dip-switch. In the ISR I'm writing some data to my own IP
> core (which is an OPB slave). My OPB slave is reading some other
> dip-switches and put the result to some LEDs (yes I'm using an evaluation
> board ;). So far everything is ok. Now comes the problem: the expected
> behaviour is dependent of the code in the ISR. If I've the following ISR:
> 
> void dip_isr(void)
> {
>  *(opb_mycore_base) = 0x12345678;
> 
>  // Write the value of j to the LED
> // XGpio_DiscreteWrite(&gp_out, 0);
> 
> #ifdef USE_INTC
>  XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK);
> #endif
> }
> 
> it's not working. 

Can you define what you mean by "not working"?

> But if I enable the XGpio write, it is working. 

And similarly, what do you mean by "working"?

> And at
> last, if I do the XGpio write first and than the write to the OPB slave
> (opb_mycore) it's again not working anymore. 

> In all three situations, the
> code is coming in the ISR (I see that, because there is no output at the
> uart anymore, which is done in the main program).

I would hesitate to use that fact as proof that the code is entering the 
ISR...

Anyway it almost suggests like you have some issues with the OPB address 
decoding in your slave.  Either that, or some kind of bus timeout issue 
maybe.  Have you tried simulating your core?

Also, are you using the IPIF example that comes with edk3.2?  Someone 
here in our lab very recently had problems with that, the IPIF address 
decoding wasn't doing anything like what he expected.  When he dropped 
IPIF and did the OPB interface manually, it got a lot better.

Regards,

John

Sorry for the late response...

"John Williams" <jwilliams@itee.uq.edu.au> wrote in message
news:bn9j1j$c24$1@bunyip.cc.uq.edu.au...
> Hi Frank,
>
> Frank wrote:
> > I've succesfully build a microblaze system with external interrupt and
my
> > own IP core (using the opb slave template in the EDK). The interrupt is
> > connected to a dip-switch. In the ISR I'm writing some data to my own IP
> > core (which is an OPB slave). My OPB slave is reading some other
> > dip-switches and put the result to some LEDs (yes I'm using an
evaluation
> > board ;). So far everything is ok. Now comes the problem: the expected
> > behaviour is dependent of the code in the ISR. If I've the following
ISR:
> >
> > void dip_isr(void)
> > {
> >  *(opb_mycore_base) = 0x12345678;
> >
> >  // Write the value of j to the LED
> > // XGpio_DiscreteWrite(&gp_out, 0);
> >
> > #ifdef USE_INTC
> >  XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK);
> > #endif
> > }
> >
> > it's not working.
>
> Can you define what you mean by "not working"?

Well in my own user IP core, I'm reacting if there is a write access to the
base address of my IP core. The reaction is reading some dip switches and
writing a value to some leds. I can not see this behaviour when it's "not
working".

>
> > But if I enable the XGpio write, it is working.
>
> And similarly, what do you mean by "working"?

If it's working, the value of the dip switches are shown correctly at the
leds.

>
> > And at
> > last, if I do the XGpio write first and than the write to the OPB slave
> > (opb_mycore) it's again not working anymore.
>
> > In all three situations, the
> > code is coming in the ISR (I see that, because there is no output at the
> > uart anymore, which is done in the main program).
>
> I would hesitate to use that fact as proof that the code is entering the
> ISR...

I'm 100% sure that it's entering the ISR, because I also tested it with
toggling leds in the ISR.

>
> Anyway it almost suggests like you have some issues with the OPB address
> decoding in your slave.  Either that, or some kind of bus timeout issue
> maybe.  Have you tried simulating your core?

No, I haven't. At this moment, I don't know how to do that.

>
> Also, are you using the IPIF example that comes with edk3.2?  Someone
> here in our lab very recently had problems with that, the IPIF address
> decoding wasn't doing anything like what he expected.  When he dropped
> IPIF and did the OPB interface manually, it got a lot better.

Yes, I'm using the IPIF example from the EDK3.2 (I used the
opb_core_ssp0_v1_00_b). I will try it without the IPIF, but I'm still
inquisitive about the fact why it isn't working...

I have good results: it's working when I drop the IPIF address decoding
stuff and do the OPB interface manually. But if anybody knows WHY the IPIF
stuff is not working correctly, let me know...

Frank

"Frank" <someone@work.com> wrote in message
news:3f9e2b15$0$9484$edd6591c@news.versatel.net...
> Sorry for the late response...
>
> "John Williams" <jwilliams@itee.uq.edu.au> wrote in message
> news:bn9j1j$c24$1@bunyip.cc.uq.edu.au...
> > Hi Frank,
> >
> > Frank wrote:
> > > I've succesfully build a microblaze system with external interrupt and
> my
> > > own IP core (using the opb slave template in the EDK). The interrupt
is
> > > connected to a dip-switch. In the ISR I'm writing some data to my own
IP
> > > core (which is an OPB slave). My OPB slave is reading some other
> > > dip-switches and put the result to some LEDs (yes I'm using an
> evaluation
> > > board ;). So far everything is ok. Now comes the problem: the expected
> > > behaviour is dependent of the code in the ISR. If I've the following
> ISR:
> > >
> > > void dip_isr(void)
> > > {
> > >  *(opb_mycore_base) = 0x12345678;
> > >
> > >  // Write the value of j to the LED
> > > // XGpio_DiscreteWrite(&gp_out, 0);
> > >
> > > #ifdef USE_INTC
> > >  XIntc_mAckIntr(XPAR_MY_INTC_BASEADDR, XPAR_SYSTEM_MY_INT_MASK);
> > > #endif
> > > }
> > >
> > > it's not working.
> >
> > Can you define what you mean by "not working"?
>
> Well in my own user IP core, I'm reacting if there is a write access to
the
> base address of my IP core. The reaction is reading some dip switches and
> writing a value to some leds. I can not see this behaviour when it's "not
> working".
>
> >
> > > But if I enable the XGpio write, it is working.
> >
> > And similarly, what do you mean by "working"?
>
> If it's working, the value of the dip switches are shown correctly at the
> leds.
>
> >
> > > And at
> > > last, if I do the XGpio write first and than the write to the OPB
slave
> > > (opb_mycore) it's again not working anymore.
> >
> > > In all three situations, the
> > > code is coming in the ISR (I see that, because there is no output at
the
> > > uart anymore, which is done in the main program).
> >
> > I would hesitate to use that fact as proof that the code is entering the
> > ISR...
>
> I'm 100% sure that it's entering the ISR, because I also tested it with
> toggling leds in the ISR.
>
> >
> > Anyway it almost suggests like you have some issues with the OPB address
> > decoding in your slave.  Either that, or some kind of bus timeout issue
> > maybe.  Have you tried simulating your core?
>
> No, I haven't. At this moment, I don't know how to do that.
>
> >
> > Also, are you using the IPIF example that comes with edk3.2?  Someone
> > here in our lab very recently had problems with that, the IPIF address
> > decoding wasn't doing anything like what he expected.  When he dropped
> > IPIF and did the OPB interface manually, it got a lot better.
>
> Yes, I'm using the IPIF example from the EDK3.2 (I used the
> opb_core_ssp0_v1_00_b). I will try it without the IPIF, but I'm still
> inquisitive about the fact why it isn't working...
>
>
>