[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] Re: follow up on return from interrupt
From: |
Keith Gudger |
Subject: |
Re: [Simulavr-devel] Re: follow up on return from interrupt |
Date: |
Wed, 3 Dec 2003 06:45:19 -0800 (PST) |
Ted:
Thanks for the debug. So all the I/O's get read before attachment? That
explains it. I'll "not worry about it", as you say. Hopefully the next
time I'm in SJ I can get an update on my cvs tree...
Keith
On Tue, 2 Dec 2003, Theodore A. Roth wrote:
> 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
>
>
>