[U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.

[U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.

[shawn Bai]

 
Hello, guys.
 
I have 2 questions about duart on MPC837xE-rdb board.
 
1. why not implement duart driver in interrupt-driven mode, in addition to polling-mode?
   
   from the existing implementation of uboot, I find there is only polling-mode duart driver.
 
2. According to requirements from upper application, interrupt-driven mode duart driver is needed to be implemented on our board.
 
   But, there is a question on which I have spent a whole Saturday, even so, it has not been worked out yet.
 
   DUART's basic paramenters, such as character's length, stop bits' length, odd or even parity, baudrate, are configured normally, and also FIFO mode.
 
   DUART is used in interrupt-driven mode, so both external interrupt(EE in MSR), and UART1 interrupt in IPIC module is enabled. And interrupt handler routine has already been connected with DUART hardware interrupt signal.
 
   When a block of data is needed to transmit, the address of that block of data will be passed to uart driver as the parameter of uart tx function, like uint32 uart_put_buf?uchar channel, uchar *buf, uint32 len?. when run in uart_put_buf function,  interrupt THREI(transmitter holding register empty interrupt) is enabled first? then?the first data in that buf is written into uart transmitter holding register, like *((volatile uchar*)IMMRBAR + 0x4500 + 0x00) = *buf; in my opinion, the rest of datas is transmitted in interrupt handler routine when THREI interrupt happens.
 
   Here the question comes, after the first data in buf is written into uthr register, this character is displayed on the screen actually as we expect, things are going well until now, but there is no THREI interrupt signal which should be triggered by completion of the first data transmission. Because Interrupt handler routine can not be run, the rest of datas in buf cannot be transmitted.
 
   After transmission of the first data in buf, there is no vector in IPIC vector register, which indicates the highest priority interrupt pending, and also value of the interupt pending register is 0, which means there is no interrupt pending.
 
   What seems strange is the whole way interrupts will pass through is set as needed, EE in MSR, UART1 int in IPIC module, THREI int in DUART moduel, and the first data in buf is written into thr register, which will also bring the presence of THREI interrupt.
 
   But, why interrupt handler routine cannot be entered? 
 
   Are some main points missed?
 
   Could you give me some guidance?
 
   Any suggestion is welcome.
 
   Thanks a lot.
 
-Shawn
 
   
    		 	   		  

[U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.

[Albert ARIBAUD]

Hi Shawn,

Le 13/08/2011 17:33, shawn Bai a ?crit :
> 
> 
> Hello, guys.
> 
> I have 2 questions about duart on MPC837xE-rdb board.
> 
> 1. why not implement duart driver in interrupt-driven mode, in addition to polling-mode?
> 
>     from the existing implementation of uboot, I find there is only polling-mode duart driver.

Well, why would interrupts be needed for? Remember that U-Boot is not a
multi-tasking OS, but a single-thread bootloader, so we tend to use
interrupts only if there is a good case for it as far as bootloading is
concerned.

> 2. According to requirements from upper application, interrupt-driven mode duart driver is needed to be
> implemented on our board.

You mean you will run a native application directly from U-Boot? No OS
such as Linux for instance?

>     But, there is a question on which I have spent a whole Saturday, even so, it has not been worked out yet.
> 
>     DUART's basic paramenters, such as character's length, stop bits' length, odd or even parity, baudrate, are
> configured normally, and also FIFO mode.
> 
>     DUART is used in interrupt-driven mode, so both external interrupt(EE in MSR), and UART1 interrupt in
> IPIC module is enabled. And interrupt handler routine has already been connected with DUART hardware
> interrupt signal.
> 
>     When a block of data is needed to transmit, the address of that block of data will be passed to uart driver
> as the parameter of uart tx function, like uint32 uart_put_buf?uchar channel, uchar *buf, uint32 len?.
> when run in uart_put_buf function,  interrupt THREI(transmitter holding register empty interrupt) is enabled
> first? then?the first data in that buf is written into uart transmitter holding register, like
>*((volatile uchar*)IMMRBAR + 0x4500 + 0x00) = *buf;

(oh God. Does your code really have this line as you show it?)

> in my opinion, the rest of datas is transmitted in interrupt handler routine when THREI interrupt happens.

That is the usual design, yes.

>     Here the question comes, after the first data in buf is written into uthr register, this character is displayed
> on the screen actually as we expect, things are going well until now, but there is no THREI interrupt signal
> which should be triggered by completion of the first data transmission. Because Interrupt handler routine
> can not be run, the rest of datas in buf cannot be transmitted.
>
>     After transmission of the first data in buf, there is no vector in IPIC vector register, which indicates the highest priority interrupt pending, and also value of the interupt pending register is 0, which means there is no interrupt pending.
> 
>     What seems strange is the whole way interrupts will pass through is set as needed, EE in MSR, UART1 int in IPIC module, THREI int in DUART moduel, and the first data in buf is written into thr register, which will also bring the presence of THREI interrupt.
> 
>     But, why interrupt handler routine cannot be entered?

Hard to tell. That is your code, not U-Boot's. Plus I don't know your
UART -- I am ashamed to tell I only deal(t) with 8250/16550-like UARTs,
which emit a THRE every time you can write again to the xmit buffer, and
I never saw such a problem as you expose.

>     Are some main points missed?

I could hardly tell, but what I can tell is that your problem in itself
is a reason why using interrupts without a cause should be avoided. I do
understand you have it as a requirement, but then it seems you have two
conflicting requirements: use interrupts and run directly atop of U-Boot.

>     Could you give me some guidance?
> 
>     Any suggestion is welcome.

Well, I can only offer generic advice: use a JTAG probe to break when
your interrupt handler is entered and see what it does then: does it
indeed write a character out? If it does, examine the UART's status
bits: does it say it is busy transmitting? Does it say its xmit buffer
is free (independently of raising an interrupt). Is the *whole* chain if
interrupt handling correctly ackowledged after the interrupt? Etc.

But the best advice I can offer is: if you have a requirement of
interrupt-driven application behavior, do not run an application right
above U-Boot; use a real-time OS of sorts, including Linux ones.

>     Thanks a lot.

np

> -Shawn

Amicalement,
-- 
Albert.