[U-Boot] Question about interrupt-driven mode duart on MPC837xE-rdb board.(with the subject)

[shawn Bai]

 Hi, Albert,

 Sorry, I don't know the reason why I cannot receive your email,
 and your email-address cannot be seen either.

 So text following is copied from mailing list.

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

 Well, I see. This is the answer I wanna know for a period of time.

 Speaking of interrupt-driven mode DUART, it depens on the requirement from upper application.

 DUART is used in redundant communication. Each end on DUART has no idea when the data from the other

 end will come. and the cpu time cannot be wasted on waiting, even a little. So interrupt-driven mode

 DUART is what we want.

 >> 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?

 Actually, not directly based on u-boot, which is referenced often.

 But the process is very very similar.

 There is a mainloop in uboot code. Accordingly, in our project, after the boot process, the main()

 function will also be entered, and cannot return.

 There is no any OS, and just a while(1){...} loop in the main() function.

 things are done in the while loop.

 >> 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?)

 yes,

 to reference duart peripheral in mpc837xe-rdb board, structure duart83xx_t defined by uboot is used.

 first, define a pointer, duart83xx_t *p_base = NULL;

 then make p_base equal to ( (duart83xx_t *)(IMMRBAR + 0x4500 + (channel-1) * (0x1 << 8) ) ), according to the uart channel used now.

 after that, statement uthr = *buf> will put the first data in buf into thr register.

 and the buf and length passed by user is stored in 2 global variables, which are used in DUART ISR.
 like g_tranbuf = buf + 1; /* 'cause first data in buf is transmitted in the funcion*/
 g_tranlength = len - 1; /*the same reason as above*/

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

 yes, it is the code of my own, not uboot.

 In mpc837xe manual, it is said that DUART programming is PC16552D compatible.

 The machanism you said is the fundation of interrupt-driven transmission.

 And I also think so.

 To accomplish it, I enabled external interupt(EE, bit16 in MSR), UART1 INT(bit24 in simrh) in IPIC

 module, and THRE INT(bit6 in ier) in DUART module.

 Interrupt handler routine is already connected with UART1 INT in IPIC, after this, once UART1  interrupt happens, the handler routine will be called.

 Strangely, handler routine is called once or twice, but right after THRE is enabled in uart_put_buf

 function. In DUART handler routine, IP(interrupt pending bit in iir, interrupt identification register) is checked, if it is 1, then no interrupt is pending. handler routine will return.

 Even if entered, handler routine will return in this if branch.

 >> 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.
 > 
 Upper level applications have no idea how DUART transmission is implemented. But one thing must be

 ensured, which is that do not waste cpu time, and is as real-time as possible.

 So interrupt-driven mode is the choice.

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

 CodeWarrior USB Tap is the JTAG tool used now.

 the first data in buf in transmitted in uart_put_buf(), not in handler routine.

 And the first data is already seen from PC display.

 I thought THRE INT will be triggered, but not.

 To recognize the event causing interrupt, IIR(interrupt identification register) should be read when

 interrupt-driven mode is used, and bit7 in it should be 0, which indicated there is interrupt pending

 in current DUART channel. Buf in fact， it is 1, so there is no further handling to happen.

 The transmitter status in LSR(line status register), is 1, which implies there is space for the next

 data, but in interrupt-driven mode, we depend on THRE INT in IIR.

 OS is out of our consideration now, and it is not determined by myself.

 So many thanks for the help.

 -Shawn

 >> Thanks a lot.

 >np

 >> -Shawn

 >Amicalement,
 >--
 >Albert.