problem with simulation of amforth in simavr

133 views
Skip to first unread message

wzab

unread,
Nov 10, 2013, 1:54:01 PM11/10/13
to sim...@googlegroups.com
Hi,
Last time I returned to my old project based on amforth ( http://amforth.sf.net ) and wanted to simulate it in simavr with terminal connected via pty.
It was relatively easy to pathc the run_avr application to add the uart_pty support:

*** /tmp/sa/simavr/simavr/sim/run_avr.c    2013-11-10 19:20:59.562394701 +0100
--- run_avr.c    2013-11-09 14:33:16.161296139 +0100
***************
*** 31,36 ****
--- 31,38 ----
  #include "sim_hex.h"
 
  #include "sim_core_decl.h"
+ #include "uart_pty.h"
+ uart_pty_t uart_pty;
 
  void display_usage(char * app)
  {
***************
*** 172,177 ****
--- 174,183 ----
          avr_gdb_init(avr);
      }
 
+     uart_pty_init(avr, &uart_pty);
+     uart_pty_connect(&uart_pty, '0');
+
+
      signal(SIGINT, sig_int);
      signal(SIGTERM, sig_int);
 
*** /tmp/sa/simavr/simavr/Makefile    2013-11-10 19:20:59.554394700 +0100
--- Makefile    2013-11-09 14:38:09.849305555 +0100
***************
*** 35,46 ****
  include ../Makefile.common
 
  cores    := ${wildcard cores/*.c}
! sim        := ${wildcard sim/sim_*.c} ${wildcard sim/avr_*.c}
  sim_o     := ${patsubst sim/%.c, ${OBJ}/%.o, ${sim}}
 
  VPATH    = cores
  VPATH    += sim
 
  IPATH    = sim
  IPATH    += .
  IPATH    += ../../shared
--- 35,48 ----
  include ../Makefile.common
 
  cores    := ${wildcard cores/*.c}
! sim        := ${wildcard sim/sim_*.c} ${wildcard sim/avr_*.c} ${wildcard sim/uart_*.c} 
  sim_o     := ${patsubst sim/%.c, ${OBJ}/%.o, ${sim}}
 
  VPATH    = cores
  VPATH    += sim
 
+ LDFLAGS += -lpthread -lutil
+
  IPATH    = sim
  IPATH    += .
  IPATH    += ../../shared

I have also generated the working amforth image for atmega328p using the amforth-5.1/appl/template sources in the amforth-5.1 distribution.
The correct operation I have verified using the bare metal atmega328p microcontroller.

Afterwards I have created the hex file suited for loading into the simavr:

FWARE=/home/wzab/amforth-5.1/appl/template/template
srec_cat $FWARE.eep.hex -Intel -fill 0xff 0x0 0x400 -offset 0x810000 $FWARE.hex -Intel -fill 0xff 0 32768 -output amforth.hex -Intel -multiple  -Line_Length 44

Started the simavr:
$ ./run_avr -m atmega328p -f 8000000 -g
avr_gdb_init listening on port 1234
uart_pty_init bridge on port *** /dev/pts/10 ***
uart_pty_connect: /tmp/simavr-uart0 now points to /dev/pts/10
note: export SIMAVR_UART_XTERM=1 and install picocom to get a terminal

Then minicom:
$ minicom -o -D /dev/pts/10

And gdb:
 avr-gdb -x gdb.script

where gdb.script contained:
target remote localhost:1234
load whole.hex
continue

Afterwards I was able to get the Amforth prompt in the picocom,
and I was able to use compiled-in words:

Welcome to minicom 2.6.2

OPTIONS: I18n
Compiled on Feb  7 2013, 21:36:21.
Port /dev/pts/10, 19:39:56

Press CTRL-A Z for help on special keys

amforth 5.1 ATmega328P
> 10
 ok
> 20
 ok
> +
 ok
> .
30  ok
>

The problem occurs however, when I try to compile any new word:
> : test 10 20 + . ;
 ok
> test

The simulated amforth hangs forever.

To investigate the problem, I have uncommented printd in avr_eeprom.c and avr_flash.c sources, and it seems,
that the problem is associated with the way how simavr simulates writing to the flash and/or eeprom memory.
I'll be grateful if anybody could check/confirm my findings and provide any pointers how to investigate and fix that propblem.

--
Regards,
Wojtek


wzab

unread,
Nov 10, 2013, 3:03:37 PM11/10/13
to sim...@googlegroups.com
Of course in the description in the first post, the gdb.script should contain:

target remote localhost:1234
load amforth.hex
continue
--
Regards,
Wojtek

wzab

unread,
Nov 14, 2013, 5:44:39 AM11/14/13
to sim...@googlegroups.com
I have found, that when I define a new word, Amforth perform multiple writes to consecutive locations in the FLASH memory and it results in the following SPM operations:

In Amforth:

: test 12 ;

 ok  

In the simavr output with enabled printing of SPM operations:

AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ff04
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:6574
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:7473
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:3bb6
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:3837
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:000c
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
AVR_IOCTL_FLASH_SPM 01 Z:1b00 R01:ff01
AVR_IOCTL_FLASH_SPM 01 Z:1b02 R01:003f
AVR_IOCTL_FLASH_SPM 01 Z:1b04 R01:0d73
AVR_IOCTL_FLASH_SPM 01 Z:1b06 R01:3800
AVR_IOCTL_FLASH_SPM 01 Z:1b08 R01:3870
AVR_IOCTL_FLASH_SPM 01 Z:1b0a R01:03be
AVR_IOCTL_FLASH_SPM 01 Z:1b0c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b0e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b10 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b12 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b14 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b16 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b18 R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1a R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b1c R01:381a
AVR_IOCTL_FLASH_SPM 01 Z:1b1e R01:ffff
AVR_IOCTL_FLASH_SPM 01 Z:1b20 R01:ffff
[...]
So it seems, that simavr loses information about previous writes, when performing write to the next location...
Regards,
Wojtek

M P

unread,
Nov 14, 2013, 5:47:27 AM11/14/13
to simavr
Hi; 

Not totally sure how it's supposed to behave; haven't worked on that bit in years, "it works" is what was I said when the bootloader wrote a firmware successfully :-)

I'll have a quick look..
M



--
You received this message because you are subscribed to the Google Groups "simavr" group.
To unsubscribe from this group and stop receiving emails from it, send an email to simavr+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

wzab

unread,
Nov 14, 2013, 12:27:38 PM11/14/13
to sim...@googlegroups.com


W dniu czwartek, 14 listopada 2013 11:47:27 UTC+1 użytkownik buserror napisał:
Hi; 

Not totally sure how it's supposed to behave; haven't worked on that bit in years, "it works" is what was I said when the bootloader wrote a firmware successfully :-)

I'll have a quick look..
M

Thanks, to provide you with the full picture, I attach the whole output of simavr in the verbose mode
 
rep.txt.gz

wzab

unread,
Nov 14, 2013, 12:40:16 PM11/14/13
to sim...@googlegroups.com
Well, I have modified the FLASH writing routine in a very simple way.
If the page is not erased, it is only possible to change the bits from 1 to 0.

So I've changed the following part of code:

ORIGINAL VERSION:

static int avr_flash_ioctl(struct avr_io_t * port, uint32_t ctl, void * io_param)
{

 [...]
    } else {
        z &= ~1;
        avr->flash[z++] = r01;
        avr->flash[z] = r01 >> 8;
    }
    return 0;
}

PATCHED VERSION:

static int avr_flash_ioctl(struct avr_io_t * port, uint32_t ctl, void * io_param)
{

 [...]
    } else {
        z &= ~1;
        avr->flash[z++] &= r01;
        avr->flash[z] &= (r01 >> 8);
    }
    return 0;
}

Now it seems, that simavr simulates correctly. However I've not analyzed it sufficiently to state that this dirty trick has not broken something else...

Regards,
Wojtek

wzab

unread,
Nov 14, 2013, 1:04:23 PM11/14/13
to sim...@googlegroups.com
Attached is a patch implementing described changes.
Regards,
Wojciech Zabołotny
patch.txt

M P

unread,
Nov 15, 2013, 7:12:57 AM11/15/13
to simavr
thanks, its' supposed to be how flash behave anyway, I'm surprised I never picked it up when I wrote that originally. Will apply ASAP.
It's likely it was never picked up because the bootloader alwas write the whole words after a page erase
M



--
Reply all
Reply to author
Forward
0 new messages