Re: [Simulavr-devel] Whats to do on execution of "illegal instruction"

[Albrecht Frenzel]

> (I don't think simulavr has a notion of a BOOTRST fuse, so it always
> starts from $pc = 0.)
Sometimes it starts on the correct bootloader start address. Since 
simulavr terminates on ffff, that means that "sometimes" the fuses 
are checked.

Since the gdb-server waits until gdb is connected, it can't be 
difficult to execute a power on reset immediatly after connection.

Regarding ffff: It doesn't make sense to treat this code regularly 
as SBRS r31, 7 - the code is officially undefined and because of its 
complex behaviour no candidate to fill patch areas with. (I guess, 
the age of patch areas endet in the late 1970ies or so and nobody 
will use this technique nowadays.) Remains, that the controller has 
run into noman's land.

> On Fri, 5 Feb 2016, Klaus Rudolph wrote:
>
> 0xFFFF should be a separate case from all other invalid instructions.
> It seems to me that run-time configuration should include both the
> effect on the simulatee and on the output text.
> There is potential for a lot of output.
What potential?
For my opinion, it should send the cpu registers and a message 
"invalid opcode xxxx" or something like that to stdout and send a 
"software breakpoint" to gdb. That should be done for any invalid 
instruction.


Might it be possible to define a register, which is accessible from 
gdb (and not by µc software)? If yes: this might be the hook to 
trigger reset from gdb.


I setup a code:blocks project for simulavr - make works, but gdb 
currently not. Does anybody use cb on linux for developing simulavr?

Albrecht



On 05.02.2016 23:27, Joerg Wunsch wrote:
> As David Madden wrote:
>
> > On 2/5/16 2:11 PM, Joerg Wunsch wrote:
> > > The difference is negligible, it's only a matter whether each
> > > instruction is going to be executed, or each second one.
> > Yikes, I wouldn't call that negligible
> OK, negligible for the case where you run into it straight from reset.
>
> But that's the most common case, and the one Albrecht ran into.  (I
> don't think simulavr has a notion of a BOOTRST fuse, so it always
> starts from $pc = 0.)
>
> > Hmmm, maybe I'll run some tests this weekend on the AVRs I have around.
> >   It would be interesting to see what happens.
> If you look into that old thread I quoted, it contains some test code.