On 21.02.2016 20:48, Thomas K wrote:
To answer Albrechts question about who use simulavr: that's the
problem of all - it could be from 5 to thousands ... :-) In normal
distributions simulavr package is available - but in version
0.1.2.6! For debian a package maintainer is wanted. I assume, that
How many users of simulavr recently use it (or plan) to simulate
tiny11/12/15 or at90s1200?
Does anybody know, how many people really use simulavr?
On 21.02.2016 08:18, Klaus wrote:
Hi all,
So the question is: is there a need to implement tiny11/12/15?
(at90s1200 is to old, I think) If n
Here is a listing of very strange debugging session on simulavr w/
atmega 328p:
(gdb) load
Loading section .text, size 0x1f2 lma 0x7e00
Loading section .version, size 0x2 lma 0x7ffe
Start address 0x7e00, load size 500
Transfer rate: 244 KB/sec, 250 bytes/write.
(gdb) i r
...
r280xaa
Chapter 7.5.1 "SPH and SPL – Stack Pointer High and Stack Pointer
Low Register" of the atmega 48/88/168/328 says, that the initial
value of SP is RAMEND.
simulavr terminates with assert(0 != SP_value), if SP==0, no matter,
which instruction is executed. That means, that programmaticaly
loadin
Regarding the assertion: assert(0 != SP_value)
Startup code in CRT (a C runtime) is expected initialize SPH:SPL to a
sane value - a value that points to RAM. Having SPH:SPL point to 0 (or
anywhere but RAM) indicates problem in simulated AVR code - not a
problem in simulavr iself.
That's not true
Most invalid instructions should default to break
An optional break ist very useful for debug, but "most invalid
instructions" implies, that there should be exceptions. Which and why?
Some invalid instructions, e.g. 0x,
should have an instruction-specific default, e.g. NOP.
That means, a
Hello,
In the mean time, people trying to simulate bootloaders can:
(a) attach gdb and execute $pc=0x7e00 command
(b) add one instruction to .vectors sections, not to the usual .text
section (note 1)
(c) we can add code to read fuses from the ELF file. (Note 2)
Thanks to Thomas, this issue has be
at first: Please use latest git master content. The version 1.0.0 contains so
many bugs that I can not answer any question to that outdated version.
Wouldn't it be a good idea, to remove this version and put a better
one onto the project home page?
On 10.02.2016 17:50, Klaus Rudolph wrote:
For my opinion, there is no need to produce messages for correct
behaviour of the simulator.
A message should have been produced for the irregular behaviour
before Thomas' fix, but this is past now, at least (?) for atmega
48...328.
Thanks Thomas for your fast fix.
Albrecht
On 09.02.2016
Maybe: "--invalid-opcode=(ffnop|break|abort)"
ffnop - FF FF interpreted as NOP without any message (or SBRS r31,7)
break - behaviour like breakpoint with message
abort - (the default) abort simulation with a message
I could live with that.
I think, translating ff ff to NOP is not a good idea.
(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 , that means that "sometimes" the fuses
are checked.
Since the gdb-server waits until gdb is connected, it ca
So the problem is to find a solution which fits for most needs.
Simply add a commandline option --treat-invalid-opc-as-break
Albrecht
On 05.02.2016 14:28, Klaus Rudolph wrote:
Hi again,
I want to start a discussion how we should implement a "illegal instruction"
execution. Current behavior
If we plan to do this change we must support the current
implementation. Maybe a command line switch to extend the instruction set for
"undefined" instruction for personal use? Changing the default behavior is not
acceptable for my use cases.
Regards
Klaus
Gesendet: Freitag, 05. F
As the AVR (undocumentedly) treats opcode as a NOP, I think
the simulator could even just continue.
That's a good idea, but why not make it configurable: in normal mode
it is NOP, but on demand can act as BREAK?
Albrecht
On 05.02.2016 08:02, Joerg Wunsch wrote:
As Alb
My command sequence:
simulavr -G -d atmega328 -f boot.elf
ddd --debugger avr-gdb
file boot.elf
simulavr-devel@nongnu.org
stepi
simulavr terminates:
--
Sent:
$98e1908380830895eddf803219f088e0f5dfffcf84e1dfcfcf93c82fe3dfc150e9f7cf91f1cf282e80e0e8dfe0e0ff2
cmd/gdbserver.cpp:734 int GdbServer::gdb_get_addr_len(const char
*pkt, char a_end, char l_end, unsigned int *addr, int *len)
doesn't find the end of memory. Looks like memory corruption...
Albrecht
On 31.01.2016 15:27, Albrecht Frenzel wrote:
Here is the tail of 'simulavr -G -d at
on `0 <= addr &&
(unsigned) addr+1 < core->Flash->GetSize()' failed.
Aborted
---
The code is a bootloader.
Command sequence in ddd was:
(gdb) file boot.elf
Reading symbols from boot.elf...done.
(gdb) target remote localhost:1212
Remote debugging using localhost:1212
Output from simulavr:
$ simulavr -g -d atmega328 -f boot.elf
Waiting on port 1212 for gdb client to connect...
Connection opened by host 127.0.0.1, port -10566.
simulavr: cmd/gdbserver.cpp:320: word
GdbServer::avr_core_flash_read(int): Assertion `0 <= addr &&
(unsigned) addr+1 < core->Flash->Ge
s the issue.
Best regards
Albrecht
On 31.01.2016 11:22, Albrecht Frenzel wrote:
Hi Thomas,
the path is /usr/local/lib/. After ldconfig -n /usr/local/lib/ it
worked.
Thanks
Albrecht
On 31.01.2016 09:17, Thomas K wrote:
Hi Albrecht,
if this works:
> LD_LIBRARY_PATH= simulavr
then you
e this problem happens because of 64bit
version and not detecting the right path while installing. Where
is libsim.so installed on your machine?
cu, Thomas
Am 30.01.2016 um 23:44 schrieb Albrecht Frenzel:
Hi Klaus,
build finished successfully, but launching simulavr ends up in
simulavr: error
Please read also options for ./configure if you need verilog or
tcl support.
Regards
Klaus
Am 30.01.2016 um 19:32 schrieb Albrecht Frenzel:
Hi Klaus,
I guess, but don't know, that
https://github.com/Traumflug/simulavr.git
is the repo, you meant.
I cloned it and tried to build, but f
head. 1.0.0. is outdated and broken in many aspects.
Maybe this also fits your documentation issues.
Regards
Klaus
Am 29.01.2016 um 16:47 schrieb Albrecht Frenzel:
g++ complains on systemclock.cpp:70:23:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/usr/include -g -O2
-Icmd
-Iui -Ihwtim
make[2]: Entering directory `/tmp/simulavr-1.0.0/doc'
restore=: && backupdir=".am$$" && \
rm -rf $backupdir && mkdir $backupdir && \
if (/bin/bash /tmp/simulavr-1.0.0/missing --run makeinfo
--version) >/dev/null 2>&1; then \
for f in simulavr.info simulavr.info-[0-9]
simulavr.info
g++ complains on systemclock.cpp:70:23:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I/usr/include -g -O2 -Icmd -Iui
-Ihwtimer -c systemclock.cpp -o .libs/systemclock.o
systemclock.cpp: In instantiation of ‘void MinHeap::Insert(Key,
Value) [with Key = long long int; Value = SimulationMember*]’:
What is the simulavrxx project home page?
How to get the current version?
Where is your repository?
___
Simulavr-devel mailing list
Simulavr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/simulavr-devel
25 matches
Mail list logo
