amforth-devel

Re: [Amforth] Development request

[Mikael N. <mik...@pp...>]

Hi Enoch,
For your information, FlashForth has these robustness mechanisms built
in.

The aim has been to make it so robust that a reflash should never be
needed.

The Kernel is write protected, the memory allocation pointers in eeprom
are initialized from write protected flash with the EMPTY command.

At boot time all dynamic data is first initialized from write protected
flash.
It is then up to the application to do whatever further initialization
that is needed. That also includes setting up the application dependent
IRQ vectors in ram. 

MARKER is also supported. it restores flash, eeprom and ram allocation
pointers. 


BR Mikael

http://flashforth.sourceforge.net

Re: [Amforth] Development request

[Enoch <ix...@ho...>]

Mikael Nordman <mik...@pp...>
writes:

> Hi Enoch,
> For your information, FlashForth has these robustness mechanisms built
> in.
>
> The aim has been to make it so robust that a reflash should never be
> needed.
>
> The Kernel is write protected, the memory allocation pointers in eeprom
> are initialized from write protected flash with the EMPTY command.
>
> At boot time all dynamic data is first initialized from write protected
> flash.
> It is then up to the application to do whatever further initialization
> that is needed. That also includes setting up the application dependent
> IRQ vectors in ram. 
>
> MARKER is also supported. it restores flash, eeprom and ram allocation
> pointers. 
>
>
> BR Mikael
>
> http://flashforth.sourceforge.net

Thanks, I thought that your work was just Microchip centric.

Generally speaking, I prefer OSS development efforts to be merge-ing
rather than fork-ing :-)

Before selecting "Amforth" I tested the "avrforth" project which I found
quite dormant. Project development activity is one of the deciding
factors and Amforth, thanks to Matthias relentless work, gets very high
marks.

Sincerely, Enoch.

>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb

Re: [Amforth] Development request

[Matthias T. <mt...@we...>]

You drive me crazy ;)

> For your information, FlashForth has these robustness mechanisms built
> in.

One may find the new recipe "Unbreakable" worth studying.
http://amforth.sourceforge.net/TG/recipes/Unbreakable.html

Some information may be new, some are rather hidden. Some
ideas are from Michael (long ago) and some details still
need to be worked on. But that I will leave as an exercise
to the reader..

> The aim has been to make it so robust that a reflash should never be
> needed.
> 
> The Kernel is write protected, the memory allocation pointers in eeprom
> are initialized from write protected flash with the EMPTY command.
> 
> At boot time all dynamic data is first initialized from write protected
> flash.
> It is then up to the application to do whatever further initialization
> that is needed. That also includes setting up the application dependent
> IRQ vectors in ram. 

>From checking your code, I can imagine a few things that would break
FF as well. ;)

Matthias

Re: [Amforth] Development request

[Mikael N. <mik...@pp...>]

On Wed, 2013-02-27 at 19:59 +0100, Matthias Trute wrote:
> You drive me crazy ;)
Well it was not my intention :-;

> >From checking your code, I can imagine a few things that would break
> FF as well. ;)
I am interested to know what that could be.

I guess it can break but remarkably seldom. Everything related to the
startup is in write protected flash and the ram is initialized at
startup from flash so I cannot really imagine what can go wrong.
Usually when a chip starts misbehaving, it is some physical problem,
or the flash is bad and the chip needs to be replaced.

For instance, I had a very strange problem that after power-boot some
random EEPROM bytes were set to 0xff. It turned out that the PIC chip
had a minimum working voltage of 4 Volts, but the brown out reset
detection fuse was configured for 2.2 volts which is only valid for a
low voltage version of the chip.
 
mfg Mikael

Re: [Amforth] Development request

[Matthias T. <mt...@we...>]

Mikael,

>> >From checking your code, I can imagine a few things that would break
>> FF as well. ;)
> I am interested to know what that could be.

In flashforth.asm I found the following lines

        rcall   DOLIT
        .dw     dp_start
        rcall   FETCH
        rcall   TRUE_
        call    EQUAL
        call    ZEROSENSE
        breq    WARM_3
        rcall   EMPTY
WARM_3:

I read them as "if dp_start is -1, call EMPTY, otherwise
skip to WARM_3". This checks if the EEPROM got erased. Fine
so far (a common error if you forgot to flash the eeprom
hex file). But what if dp_start is something else?

I did not analyze (or even tested) this, but an invalid
turnkey action (e.g. assigning not an XT to turnkey) may be
sufficient (dp_start seems to be the turnkey vector). Than
you have no chance to recover the system automatically. (or
you have some more lines of defence...)

> I guess it can break but remarkably seldom.

Well, seldom is a relative number ;)

You check for errors, that already happened or are
possible. Its the same with security: You can do a lot
of things but someone will break in nevertheless. That
doesn't make your work bad, absolutly not!! I'm the one
who is lazy and ignorant I put all the burden to the
user ;)

Matthias

Re: [Amforth] Development request

[Mikael N. <mik...@pp...>]

On Wed, 2013-02-27 at 22:01 +0100, Matthias Trute wrote:
> Mikael,
> 
> >> >From checking your code, I can imagine a few things that would break
> >> FF as well. ;)
> > I am interested to know what that could be.
> 
> In flashforth.asm I found the following lines
> 
>         rcall   DOLIT
>         .dw     dp_start
>         rcall   FETCH
>         rcall   TRUE_
>         call    EQUAL
>         call    ZEROSENSE
>         breq    WARM_3
>         rcall   EMPTY
> WARM_3:
> 
> I read them as "if dp_start is -1, call EMPTY, otherwise
> skip to WARM_3". This checks if the EEPROM got erased. Fine
> so far (a common error if you forgot to flash the eeprom
> hex file). But what if dp_start is something else?

The idea here is that the default eeprom contents is copied from flash.
The eeprom file contains just $FFFF for the turnkey to make sure that
this copy happens.
> 
> I did not analyze (or even tested) this, but an invalid
> turnkey action (e.g. assigning not an XT to turnkey) may be
> sufficient (dp_start seems to be the turnkey vector). Than
> you have no chance to recover the system automatically. (or
> you have some more lines of defence...)
If the turnkey vector is crashing the system, sooner or later the system
will restart (ctrl-o). The turnkey can then be disabled by sending ESC
to the serial port during the two first seconds of the startup. Then you
can give manually the EMPTY command to recover.

Automatic recovery was never the goal, just to have the possibility to
interrupt the system and set it to an initial state.

This is just makes working so much easier when you don't need to reflash
the chip.

> 
> > I guess it can break but remarkably seldom.
> 
> Well, seldom is a relative number ;)
> 
> You check for errors, that already happened or are
> possible. Its the same with security: You can do a lot
> of things but someone will break in nevertheless. That
> doesn't make your work bad, absolutly not!! I'm the one
> who is lazy and ignorant I put all the burden to the
> user ;)
You are following the Forth philosophy, the user is in full control.

mfg Mikael