Re: [Simulavr-devel] ATMega48 Crash

[Knut Schwichtenberg]

Michael N. Moran wrote:
> Thanks to Kurt's inspiration, I looked into the
> sefaulting of the atmega48 and "solved" the problem
> using this patch.
Thanks for finding this.
> Apparently, we were iterating beyond the bounds
> of the initialized portion of the pinI vector.
> It seems that only the first two slots were
> initialized in the constructor for p0, and p1.
To be honest I think to use numbers instead of defines is a bad coding style.
But I don't bite the hand that feeds me ;-).

> Therefore,
> I don't know if this is a "correct" fix.
On my understanding it is correct, because tt is directly related to the number
of external interrupts. So tt should not be greater than 2 for M48.

> 
> Index: hwspi.cpp
> ===================================================================
> RCS file: /sources/simulavr/simulavrxx/src/hwspi.cpp,v
> retrieving revision 1.8
> diff -r1.8 hwspi.cpp
> 99a100
>>             core->RemoveFromCycleList(this);
> 
> Basically, I (HWSpi) now removes itself from the
> cycle list before adding itself. The act of removing
> an element from the list does *not* fail if the element
> was not already in the list.
I expect it runs, BUT there is another example named SPI and that does not have
the problems. It works on the M128 and could it be a problem with the different
ways of initializing (pointer vs. member)?

While debugging both avr / simulavrxx I saw this error to come at line 115 of
main.cpp (avr). Here the SPCR register is referenced! Now your solution is: drop
the originally in atmega48.cpp created SPI-object and replace it by the object
dynamically created - that's a solution but does it handle the problem? ;-)

This is the stack trace at "AvrDevice::AddToCycleList(Hardware *hw) {" and SPCR
= in main():

#0  AvrDevice::AddToCycleList (this=0x808d858, hw=0x81a09e8) at
/usr/include/c++/4.2.1/bits/stl_algo.h:327
#1  0xb7bdf2b2 in HWSpi::SetSpcr (this=0x81a09e8, val=200 '�') at hwspi.cpp:100
#2  0xb7bdf52d in RWSpcr::operator= (this=0x81a15a0, val=200 '�') at 
hwspi.cpp:520
#3  0xb7c003ba in RWMemoryMembers::operator= (this=0x81a15a0, address@hidden) at
rwmem.cpp:45
#4  0xb7bbdc77 in avr_op_OUT::operator() (this=0x81ac928) at decoder.cpp:1545
#5  0xb7bb80c4 in AvrDevice::Step (this=0x808d858,
address@hidden,
    nextStepIn_ns=0xbfa77ad8) at avrdevice.cpp:350
#6  0xb7c0beef in SystemClock::Step (this=0xb7cafae0,
address@hidden)
    at systemclock.cpp:84
#7  0xb7c0c637 in SystemClock::Endless (this=0xb7cafae0) at systemclock.cpp:145
#8  0xb7b9e096 in _wrap_SystemClock_Endless (clientData=0x8093d60,
interp=0x804d508, objc=2, objv=0x804f3cc)
    at simulavr_wrap.cxx:6405
#9  0xb7b86fb0 in SWIG_Tcl_MethodCommand (clientData=0x8093d60,
interp=0x804d508, objc=2, _objv=0x804f3cc)
    at simulavr_wrap.cxx:1256
#10 0xb7e71f05 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so
#11 0xb7e9e908 in ?? () from /usr/lib/libtcl8.4.so
#12 0x0804d508 in ?? ()
#13 0x00000002 in ?? ()
#14 0x0804f3cc in ?? ()
#15 0x00000000 in ?? ()

> I do not claim to actually understand the use of
> the CycleList family of calls and any "documentation"/
> comments is ... well ... missing. ;)
Well as usual for lots of PD-projects we can be glad to have a user manual. A
German colleague always says: The code is the documentation - but means the
German "Kot", which is spoke like code and has a little different meaning...

Feel free to start with programmers documentation :-).

Knut