Re: Uartlite - ulite_transmit

[Michal Simek <monstr@monstr.eu>]

Michal Simek wrote:
> Peter Korsgaard wrote:
>>>>>>> "Michal" == Michal Simek <monstr@monstr.eu> writes:
>>
>> Hi,
>>
>>  >> But I still don't understand why you would want to burn CPU spinning
>>  >> when you know the UART will be busy for a while. Leaving it alone
>>  >> until it generates the TX fifo empty interrupt seems more logical to
>>  >> me.
>>
>>  Michal> I didn't know when tx fifo was full and then empty interrupt is
>>  Michal> generated. I have added some debug things to driver and I am 
>> going to
>>  Michal> look into.
>>
>>  Michal> I just changed return value and I have got correct output and
>>  Michal> then I sent this email to check if is correct or not.
>>
>> According to the spec, you should get an interrupt when RX !empty or TX
>> empty.
>>
>> We wouldn't ever be able to send more bytes than fits in the TX fifo if
>> it didn't.
> 
> Yes, I know.
> 
> I looked at that loop and I think that we should reread actual status 
> before ulite_transmit because status reg can be changed when 
> ulite_receive is executed. What do you think? (BTW: status reading can 
> be moved directly to ulite_receive/transmit functions)
> 
>     do {
>         int stat = ioread32be(port->membase + ULITE_STATUS);
>         busy  = ulite_receive(port, stat);
>         stat = ioread32be(port->membase + ULITE_STATUS); // check status 
> again
>         busy |= ulite_transmit(port, stat);
>         n++;
>     } while (busy);
> 
> 
> 
> I did some investigating and I found:
> 1. xmit circ buffer contains what needs to be printed but it is not 
> printed.
> 
> Here is circ_buf structure, pointer to buffer and head/tail
> 
> struct circ_buf {
>     char *buf;
>     int head;
>     int tail;
> };
> 
> 
> Part of the broken log. ( There should be in Welcome to and log)
> 
> adding dns 172.16.0.5
>  >
>  >  >> Yeah, that loop should probably be time based (and perhaps 
> calculated
>  >  >> from baud rate).
>  >
>  >  Michal> It is hard to say if you can find out any accurate number of 
> loops
>  >  Michal> which is baud rate dependent.
>  >
>  > Not loops, microseconds (or rather jiffies).
>  >
> adding dns 172.16.10.1
> Starting portmap:
> Starting uWeb server:
> 
> Welc
> mdm login:
> 
> Here is the circ buffer:
> (NOTE: mdm login is coming from getty and it is at the beginning)
> 
> 5ed72000: 0d0d0a6d 646d206c 6f67696e 3a20200d    ...mdm login:  .
> 5ed72010: 0a4d6f75 6e74696e 67207661 723a200d    .Mounting var: .
> 5ed72020: 0a506f70 756c6174 696e6720 2f766172    .Populating /var
> 5ed72030: 3a200d0a 52756e6e 696e6720 6c6f6361    : ..Running loca
> 5ed72040: 6c207374 61727420 73637269 7074732e    l start scripts.
> ...
> 5ed721b0: 646e7320 3137322e 31362e30 2e350d0a    dns 172.16.0.5..
> 5ed721c0: 61646469 6e672064 6e732031 37322e31    adding dns 172.1
> 5ed721d0: 362e3130 2e310d0a 53746172 74696e67    6.10.1..Starting
> 5ed721e0: 20706f72 746d6170 3a0d0a53 74617274     portmap:..Start
> 5ed721f0: 696e6720 75576562 20736572 7665723a    ing uWeb server:
> 5ed72200: 0d0a0d0a 57656c63 6f6d6520 746f0d0a    ....Welcome to..
> 5ed72210: 205f5f5f 5f5f2020 20202020 205f2020     _____       _
> 5ed72220: 20202020 20202020 205f2020 20202020             _
> 5ed72230: 5f0d0a7c 205f5f5f 205c2020 2020207c    _..| ___ \     |
> 5ed72240: 207c2020 20202020 2020207c 207c2020     |         | |
> 5ed72250: 2020285f 290d0a7c 207c5f2f 202f205f      (_)..| |_/ / _
> 5ed72260: 5f5f207c 207c5f20 20205f5f 205f207c    __ | |_   __ _ |
> 5ed72270: 207c2020 2020205f 20205f20 5f5f2020     |     _  _ __
> 5ed72280: 205f2020 205f205f 5f20205f 5f0d0a7c     _   _ __  __..|
> 5ed72290: 20205f5f 2f202f20 5f205c7c 205f5f7c      __/ / _ \| __|
> 5ed722a0: 202f205f 60207c7c 207c2020 20207c20     / _` || |    |
> 5ed722b0: 7c7c2027 5f205c20 7c207c20 7c207c5c    || '_ \ | | | |\
> 5ed722c0: 205c2f20 2f0d0a7c 207c2020 207c2020     \/ /..| |   |
> 5ed722d0: 5f5f2f7c 207c5f20 7c20285f 7c207c7c    __/| |_ | (_| ||
> 5ed722e0: 207c5f5f 5f5f7c20 7c7c207c 207c207c     |____| || | | |
> 5ed722f0: 7c207c5f 7c207c20 3e20203c 0d0a5c5f    | |_| | >  <..\_
> 5ed72300: 7c202020 205c5f5f 5f7c205c 5f5f7c20    |    \___| \__|
> 5ed72310: 5c5f5f2c 5f7c5c5f 5f5f5f5f 2f7c5f7c    \__,_|\_____/|_|
> 5ed72320: 7c5f7c20 7c5f7c20 5c5f5f2c 5f7c2f5f    |_| |_| \__,_|/_
> 5ed72330: 2f5c5f5c 0d0a0d0a 6f6e206d 646d0d0a    /\_\....on mdm..
> 5ed72340: 0d0a0000 00000000 00000000 00000000    ................
> 
> I look at head and tail values and they are OK "c" (in Welc) is called.
> Exact values are: head:0x342, tail:208.(You can check that it is correct 
> range in circ buffer)
> 
> Let me describe what driver did:
> 
> 1. Before fault happen:
> ISR is called, status is 0x18 (interrupt enabled, tx fifo full) just to 
> ulite_transmit and detect TXFULL and return to ISR. Head and tail are 
> correct
> 2. Broken part
> ISR is called, status is 0x14 (interrupt enabled, tx fifo empty), jump 
> to ulite_transmit. Here I am printing (head and tail values are zero). 
> Xmit buffer address is the same. Then uart_circ_empty(xmit) detects that 
> head and tail are the same which means nothing to print.
> 
> My question: Is there any part of the code which can change xmit head 
> and tail values?
> 
> I will try to setup watchpoints on that addresses to see which part of 
> the code is breaking that addresses.

uart_circ_clear reset circ head/tail values from uart_flush_buffer.

crisv10.c and 68360serial.c implement wait_until_sent function which is 
probably what I need to implement.

Michal

-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian