Re: [microblaze-uclinux] regarding interrupt handling on microblaze

[John Williams <jwilliams@xxxxxxxxxxxxxx>]

Hi Anand,

anand_12 wrote:

 >  I am still stuck with my "sash prompt not accepting user input"
 > problem.I am trying to get uClinux booting on my
 > Insight memec spartan 2e 600lc (microblaze) board...

Can you please post your MHS file?

Also, confirm that the information in the struct initialiser near line 
182 of xmbserial.c corresponds accurately to the base address and IRQ 
number of your uartlite peripheral(s).

See other comments below:

>  I now suspect that the keypress is not actually interrupting the processor...if i understand it right..all interrupts are handled by the interrupt controller first..which based on its priority information interrupts microblaze which then responds accordingly by servicing the interrupt...pls correct me if i am getting it wrong here itself....

that's mostly correct.  I don't think the interrupt controller actually 
inplements interrupt priority as such, excepet in a very limited way 
that I won't go into here.

>  just to test whether the processor is actually getting interrupted..i included the uart interrupt module(in addition to tx and rx) and mapped its output to a led on board...so after this i downloaded the image on to the SDRAM on board and executed it..as soon as the sash prompt appeared..when i pressed a key on the keyboard..the led's state changed...and it remained so after that....
> 
>  i concluded that the interrupt is being generated for the keypress but microblaze is not getting interrupted...else the interrupt would have been serviced and cleared subsequently which should have restored the led's old status..am i right here in concluding this way?

That seems like a good test and reasonable conclusion.  It suggests to 
me that you have a mismatch between either the base address or IRQ 
number, for your your uartlite peripheral.

> on the software side..i placed several "microblaze_gpio_write" utility funtions within the serial driver interrupt handling functions..but so far i have not been able to find out which is the exact function which is invoked when an uart interrupt occurs..i guess its xmbrs_interrupt...anyways this failure to see led values changing also probably supports my theory that microblaze is not getting interrupted in the first place in which case the ISR is never invoked...

You could put a printk statement in the xmbrs_interrupt function - it's 
a quick and dirty test to see if the interrupt handler is being invoked.

> i am not very sure..how the uart interrupt works with microblaze...can anyone briefly explain it to me...i am going through the uart controller document but i guess i am missing some fundamental concept?..thanks in advance for any help..

The uartlite generates a level sensitive interrupt - the interrupt line 
is asserted (high) whenever either of the following is true:

there is *any* data in the rx buffer OR
the tx buffer has gone from not empty to empty

See page 7 of the uartlite data sheet.

The fact that it is a level sensitive interrupt causes some problems, 
that were discussed a month or two ago.

Regards,

John



___________________________
microblaze-uclinux mailing list
microblaze-uclinux@itee.uq.edu.au
Project Home Page : http://www.itee.uq.edu.au/~jwilliams/mblaze-uclinux
Mailing List Archive : http://www.itee.uq.edu.au/~listarch/microblaze-uclinux/