OPB write actions

F

Frank

Guest
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...
 

Welcome to EDABoard.com

Sponsor

Back
Top