Re: [Simulavr-devel] UART Interrupt and Timer problem

[Jakob Schwendner]

Hi Klaus,

thanks greatly. That has fixed my testfile and also the baud problem.
I've started implementing another little test as the procyon avrlib
routines still don't seem to work fully.
Similar problem, different interrupt. UART_DATA_READY is according to
the data-sheet meant to stay on until switched off. However in my
sample code (attached below) it seems that the interrupt code body
doesn't even get called when an interrupt is raised, as a few cycles
later another one is raised again. (and so on). Also the program
generates a "Not allowed to write to Pin! Read-Only!" error. Don't
know where that comes from. Here is the trace:

    15996 ../avrtest/avrtest.elf 0x012a: __vector_31+0x2              
 IRQ DETECTED: VectorAddr: 62../avrtest/avrtest.elf IrqSystem:
IrqHandlerStarted Vec: 31
IRAM[0x10fc,,__bss_end,_end+0xfe8]=0x95 SP=0x10fb
IRAM[0x10fb,,__bss_end,_end+0xfe7]=0x00 SP=0x10fa
    16058 ../avrtest/avrtest.elf 0x007c: __SREG__,__SP_H__+0x1f       
 CPU-waitstate
    16120 ../avrtest/avrtest.elf 0x007c: __SREG__,__SP_H__+0x1f       
 CPU-waitstate
    16182 ../avrtest/avrtest.elf 0x007c: __SREG__,__SP_H__+0x1f       
 CPU-waitstate
    16244 ../avrtest/avrtest.elf 0x007c: __SREG__,__SP_H__+0x1f       
 JMP 128f0 __stack+0x8bf9
    16306 ../avrtest/avrtest.elf 0x0126: __vector_31                  
 CPU-waitstate
    16368 ../avrtest/avrtest.elf 0x0126: __vector_31                  
 CPU-waitstate
    16430 ../avrtest/avrtest.elf 0x0126: __vector_31                  
 SEI SREG=[I-------]
    16492 ../avrtest/avrtest.elf 0x0128: __vector_31+0x1              
 PUSH R1 IRAM[0x10fa,,__bss_end,_end+0xfe6]=0x00 SP=0x10f9
    16554 ../avrtest/avrtest.elf 0x012a: __vector_31+0x2              
 CPU-waitstate
    16616 ../avrtest/avrtest.elf 0x012a: __vector_31+0x2              
 IRQ DETECTED: VectorAddr: 62../avrtest/avrtest.elf IrqSystem:
IrqHandlerStarted Vec: 31
IRAM[0x10f9,,__bss_end,_end+0xfe5]=0x95 SP=0x10f8
IRAM[0x10f8,,__bss_end,_end+0xfe4]=0x00 SP=0x10f7
[...]

and the code that produced it:

//----- Include Files ---------------------------------------------------------
#include <avr/io.h>
#include <avr/signal.h>
#include <avr/interrupt.h>

#define F_CPU 16000000
#define UART1_BAUD  19200

typedef unsigned char  u08;

//----- Begin Code ------------------------------------------------------------

void io_init(void);
void uart1_send(char *s, int size);

int main(void)
{
        io_init();

        while(1) {

                char *s = "this is a test";
                uart1_send( s, 3 );

                // delay
                int m = 20000;
                while( m-- );
        }

        return 0;
}

void io_init() {
        // set LED pins for output
    DDRA = _BV(DDA2) | _BV(DDA4);       

        // set BAUD rate for UART1
        UBRR1L = ((F_CPU+(UART1_BAUD * 8L))/(UART1_BAUD * 16L)-1);
        UBRR1H = 0;

        // init UART1
        UCSR1B = _BV(TXEN); 

        // enable all interupts
        sei();
}

char *tx_buf;
u08 tx_index;
u08 tx_size;

void uart1_send(char *s, int size) {
        tx_size = size;
        tx_buf=s;
        tx_index=0;

        // enable UART data ready interrupt
        UCSR1B |= _BV(UDRIE); 
}

INTERRUPT(SIG_UART1_DATA)      
{
        // disable data ready interrupt
        UCSR1B ^= _BV(UDRIE);
         
        // check for more data
        if( tx_index < tx_size ) {
                // enable data ready interrupt
                UDR1 = tx_buf[tx_index++];      
                UCSR1B |= _BV(UDRIE); 
        } 
}



On 5/11/05, Klaus Rudolph <address@hidden> wrote:
> Hi Jakob,
> >
> > The problem I am having is that the TXC vector gets called so often,
> > where I think it shouldn't.
> 
> Yes, I can reproduce this. The problem was that after running
> to the irq handler TXC was cleared but the state TX_AFTER_STOPBIT
> could not changed anymore if TXC is allready cleared. This will result
> in an extra TXC interrupt after each bit in usart which is allways
> a stopbit...
> Problem is fixed, thanks for the message!
> 
> > Also have you got any idea why I would need to set the baud on the
> > serialrx class to 2*baud in the device? (like the device is set up for
> > 19200, yet the serialrx class needs to be
> > 38400 for it to work)
> 
> Yes, that is simply a bug. If you look inside the constructors
> from HWUart and HWUsart you will see that both classes register
> the device in the cycle list. And HWUsart is derived from HWUart and
> both constructors will register the device. The result is that
> in each core step the usart will stepped twice. Problem is solved!
> 
> I actually have no time to check in the the changes to CVS but I add my
> changes as diff in this mail.
> 
> Thanks for your very good error report!
> 
> Bye
>    Klaus
> 
> --
> +++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
> GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail
> 
>