simulavr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Simulavr-devel] Re: follow up on return from interrupt


From: Theodore A. Roth
Subject: Re: [Simulavr-devel] Re: follow up on return from interrupt
Date: Tue, 2 Dec 2003 22:05:51 -0800 (PST)

On Tue, 2 Dec 2003, Theodore A. Roth wrote:

> > Do you have any ideas about my previous problem of why I get an I/O read
> > before simulavr even gets attached?  Here's the output:
> >
> > ./simulavr -g -d atmega128
> >
> > Simulating a atmega128 device.
> >
> > MESSAGE: file decoder.c: line 3517: generating opcode lookup_table
> >
> > Enter 9 bits of hex data to read into the uart at address 0x002c:
> >
> >
> > This happens before the gdb client has done "target remote :1212".  It
> > only happens with the UART in I/O space - the UART1 in RAM space does not
> > get its read routine called.
> >
> > The 'C' code that is getting called:
> >
> > static uint8_t uart_read( VDevice *dev, int addr )
> > {
> >     UART_T *uart = (UART_T *)dev;
> >     UARTIntr_T *uart_t;
> >     int  offset  = addr - vdev_get_base(dev);
> >
> >     uart_t = (UARTIntr_T *)avr_core_get_vdev_by_name(
> >                              (AvrCore *)vdev_get_core((VDevice *)uart),
> >                                uart->int_name );
> >
> >     if ( offset == UART_UDR_ADDR )
> >     {
> >         uart_t->usr &= ~mask_RXC ; /* clear RXC bit in USR */
> >         return uart->udr_rx = uart_port_rd( addr );
> >     }
> > ...
> >
> > Any ideas as to why this gets called when the vdev gets instantiated?
> > Thanks.
> 
> Nothing strikes me as obvious. I'll try to dig into it tonight (too
> busy at work right now).
> 
> You might try running the sim in gdb. Set a break in the func that's
> getting called early and look at the backtrace when you hit the break.
> That should give you the call chain and you may see what's going on.

I added some debug output to vdev_read() and got this interesting output:

-- <output> --
address@hidden src]$ ./simulavr -g -d at90s8515
 
Simulating a at90s8515 device.
 
MESSAGE: file ../../src/decoder.c: line 3872: generating opcode lookup_table
MESSAGE: file ../../src/main.c: line 413: Simulating clock frequency of 
8000000
Hz
vdev_read called: addr = 0x28: name = 'ACSR'
vdev_read called: addr = 0x2d: name = 'SPIIntr'
vdev_read called: addr = 0x2e: name = 'SPIIntr'
vdev_read called: addr = 0x2f: name = 'SPI'
vdev_read called: addr = 0x30: name = 'PORTD'
vdev_read called: addr = 0x31: name = 'PORTD'
vdev_read called: addr = 0x32: name = 'PORTD'
vdev_read called: addr = 0x33: name = 'PORTC'
vdev_read called: addr = 0x34: name = 'PORTC'
vdev_read called: addr = 0x35: name = 'PORTC'
vdev_read called: addr = 0x36: name = 'PORTB'
vdev_read called: addr = 0x37: name = 'PORTB'
vdev_read called: addr = 0x38: name = 'PORTB'
vdev_read called: addr = 0x39: name = 'PORTA'
vdev_read called: addr = 0x3a: name = 'PORTA'
vdev_read called: addr = 0x3b: name = 'PORTA'
vdev_read called: addr = 0x3c: name = 'EEProm'
vdev_read called: addr = 0x3d: name = 'EEProm'
vdev_read called: addr = 0x3e: name = 'EEProm'
vdev_read called: addr = 0x3f: name = 'EEProm'
vdev_read called: addr = 0x41: name = 'WDTCR'
vdev_read called: addr = 0x48: name = 'OCR1B'
vdev_read called: addr = 0x49: name = 'OCR1B'
vdev_read called: addr = 0x4a: name = 'OCR1A'
vdev_read called: addr = 0x4b: name = 'OCR1A'
vdev_read called: addr = 0x4c: name = 'Timer16'
vdev_read called: addr = 0x4d: name = 'Timer16'
vdev_read called: addr = 0x4e: name = 'Timer16'
vdev_read called: addr = 0x4f: name = 'Timer16'
vdev_read called: addr = 0x52: name = 'Timer0'
vdev_read called: addr = 0x53: name = 'Timer0'
vdev_read called: addr = 0x55: name = 'MCUCR'
vdev_read called: addr = 0x58: name = 'TimerIntr'
vdev_read called: addr = 0x59: name = 'TimerIntr'
vdev_read called: addr = 0x5b: name = 'RAMPZ'
vdev_read called: addr = 0x5d: name = 'StackPointer'
vdev_read called: addr = 0x5e: name = 'StackPointer'
vdev_read called: addr = 0x5f: name = 'SREG'
Waiting on port 1212 for gdb client to connect...
-- </output> --

Here's the output from gdb when I hit the break at vdev_read():

-- <gdb output> --
Breakpoint 1, vdev_read (dev=0x8061748, addr=134587168)
    at ../../src/device.c:149
(gdb) bt
#0  vdev_read (dev=0x8061748, addr=134587168) at ../../src/device.c:149
#1  0x08054573 in mem_io_fetch (mem=0xbfffe700, addr=40, val=0xbfffe75f "", 
    buf=0x8059f0f "ORT", bufsiz=134587168) at ../../src/memory.c:261
#2  0x08049a83 in avr_core_io_display_names (core=0x805ef38)
    at ../../src/avrcore.c:629
#3  0x08053f0d in main (argc=4, argv=0xbfffe844) at ../../src/main.c:419
#4  0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) up
#1  0x08054573 in mem_io_fetch (mem=0xbfffe700, addr=40, val=0xbfffe75f "", 
    buf=0x8059f0f "ORT", bufsiz=134587168) at ../../src/memory.c:261
(gdb) up
#2  0x08049a83 in avr_core_io_display_names (core=0x805ef38)
    at ../../src/avrcore.c:629
(gdb) up
#3  0x08053f0d in main (argc=4, argv=0xbfffe844) at ../../src/main.c:419
(gdb) 
-- </gdb output> --

So here's what's going on.

main()
-> avr_core_io_display_names (global_core);
   -> mem_io_fetch (core->mem, i, &val, name, sizeof (name) - 1);
      -> *val = vdev_read (dev, addr);

This is just the simulator getting the initial values to send down stream to 
the display co-process. Even though there may not be a display co-process, 
the calls are always made.

The uart in the extended io space isn't getting tickled because 
mem_io_fetch() has hard coded the top of the IO register space at 0x5f. This 
will have to be fixed, but may have to wait until after the upcoming 
release since it's non-trivial.

Having another look at mem_io_fetch, I see that the ports don't have this 
behaviour due to a nasty little hack I made with the port_ext_disable/enable 
functions. That piece of code is not my best work.

For now, I'd say, just don't worry about this.

The changes to the vdev API I'm current thinking about should make this 
easier to deal with. I'm still hashing things out in my head right now, but 
will post some ideas once I work out the preliminary design.

One thing I really want to make go away is the mem_get_vdevice_by_name 
interface. It's a really expensive call since it most walk a dlist and it 
gets called a lot when dealing with callbacks.

Ted Roth
 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]