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

[Keith Gudger]

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