(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.
_______________________________________________
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
