flashforth-devel — FlashForth users and developers

Re: [Flashforth-devel] Warnings from assembler

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

Those registers are defined by avrasm2 to be xl, xh, zl, zh
Thats why it complains.

I have moved to XC8. It does not complain about what you have mentioned.

BR Mikael

On 2022-12-28 10:33, Helge Kruse wrote:
> I get some compiler diagnostic messages:
> 
> avr/src/macros.inc(39): warning: Register r26 already defined by the
> .DEF directive
> avr/src/ff-atmega.asm(35): info: 'avr/src/macros.inc' included from 
> here
> 
> The source code line macros.inc#39 defines the symbold t4:
> 
> .def t4 = r26
> 
> (The "already defined" warning also occurs for the registers r27, r30,
> and r31. ) Why does the assmbler complains about r26 as already 
> defined?
> Where is it defined elsewehere? I can't find a second #include 
> statement
> that would cause the file macros.inc included twice. Did I miss 
> something?
> 
> There is also a warning about "Use of undefined or forward referenced
> symbol".

[Flashforth-devel] Warnings from assembler

[Helge K. <Hel...@gm...>]

Hello

I am trying to evaulate a Forth for my ATmega2560. I want to work
interactively but also want to able to build the turnkey with the
assembler. Therefore I started with rebuilding Flashforth.

I use avrasm2 version 2.2.8 as it comes with Microchip Studio 7.0. I
changed the build script that it also finds the include file
m256def.inc. The resulting command to compile Flashfort is:

"C:\Program Files
(x86)\Atmel\Studio\7.0\toolchain\avr8\avrassembler\avrasm2.exe"-I
"C:\Program Files
(x86)\Atmel\Studio\7.0\packs\atmel\ATmega_DFP\1.6.364\avrasm\inc"
-Dffm2560 -Dop0 -I asm2/include/ avr/src/ff-atmega.asm -o
avr/hex/2560-16MHz-38400.hex -fI

The generated HEX file is identical to the HEX file in the repository.
That's great. Buit I get some compiler diagnostic messages:

avr/src/macros.inc(39): warning: Register r26 already defined by the
.DEF directive
avr/src/ff-atmega.asm(35): info: 'avr/src/macros.inc' included from here

The source code line macros.inc#39 defines the symbold t4:

.def t4 = r26

(The "already defined" warning also occurs for the registers r27, r30,
and r31. ) Why does the assmbler complains about r26 as already defined?
Where is it defined elsewehere? I can't find a second #include statement
that would cause the file macros.inc included twice. Did I miss something?

There is also a warning about "Use of undefined or forward referenced
symbol". But that's just a forward reference. It would be nice to
suppress that warning. But it looks that the assembler isn't that decent
to disable specific warnings.

Best reagards,
Helge

Re: [Flashforth-devel] Windowsterminal FlashForth -> fehlende Befehle ?

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

Hi Peter. 

*/ and */mod can be found in ff/forth/math.fs.
I always use the unsigned versions. 
These are faster and have been suitable for my applications. 

: query tib dup ti# accept 'source 2! 0 >in ! ; 

: (d.) ( d -- a u )  tuck dabs <# #s rot sign #> ;
: s.r ( adr len wid -- ) over - 0 max spaces type ;
: d.r ( d wid -- ) >r (d.) r> s.r ;
: .r ( n wid -- ) >r s>d r> d.r ;

How are you flashing the 328p without a programmer ? 

BR Mikael 

On 2022-12-21 21:27, Peter Höhne wrote:

> Hallo liebe Forthfreunde,
> 
> ich hatte den Entschluss gefasst ein Windowsterminal für mehrere Forthversionen zu schreiben.
> Darin habe ich neben eForth auch AmForth und Ihr Flashfort für den Arduino UNO/328p integriert. 
> 
> Das Umschalten inklusive Flashen des gewünschten Forth's erfolgt automatisch aus dem Programm ohne zusätzlichen Programmer oder der Arduino-IDE. Auch Stepschritte oder Teilprogramme sind bei Programmdurchlauf möglich. 
> 
> Um diese 3 Varianten besser gegenüberstellen zu können habe ich die eForth-Examples von Dr. Ting verwendet und für alle 3 Versionen aufbereitet. Sie funktionieren auch ganz gut, leider habe ich in Flashforth einige Probleme mit "nicht vorhandenen eForth-Befehlen"  wie  ->   */,   .r,  */mod,   .r   und   query 
> 
> z.B. wie in den Examples: 
> 
> Example 7  ->     : NT    ( nNT -- $ )    100 3055 */  ;
> Example 11 ->    : year ( year --, compute Julian date and leap year ) 
> dup 1949 - 1461 4 */mod   ( days since 1/1/1949 )
> Example 15 ->    : charakter ( n -- )   dup emit hex dup 3 .r 
> Example 17 ->   : getNumber ( -- n ) 
> begin cr ." Geben Sie eine Nummer ein:"  ( Nachricht ) 
> query bl word number?  Könnten Sie mir hier eventuell weiterhelfen? Ich wäre Ihnen sehr verbunden!
> Vielleicht gibt es dafür Ersatz oder Umschreibebefehle? vielen Dank für Ihre Bemühungen
> mit freundlichen Grüßen
> Peter Höhne PS: falls sie die kpl. Examples sehen wollen, den Ordner mit den FF-Examples hatte ich beigefügt
> das --> zip-File wurde aber nicht angenommen, kann es aber gern als doc-File nachsende. 
> 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

[Flashforth-devel] Windowsterminal FlashForth -> fehlende Befehle ?

[Peter H. <p.h...@we...>]

Hallo liebe Forthfreunde,

ich hatte den Entschluss gefasst ein Windowsterminal für mehrere
Forthversionen zu schreiben.
Darin habe ich neben eForth auch AmForth und Ihr Flashfort für den
Arduino UNO/328p integriert.

Das Umschalten inklusive Flashen des gewünschten Forth's erfolgt
automatisch aus dem Programm ohne zusätzlichen Programmer oder der
Arduino-IDE. Auch Stepschritte oder Teilprogramme sind bei
Programmdurchlauf möglich.


Um diese 3 Varianten besser gegenüberstellen zu können habe ich die
eForth-Examples von Dr. Ting verwendet und für alle 3 Versionen
aufbereitet. Sie funktionieren auch ganz gut, leider habe ich in
Flashforth einige Probleme mit "_nicht vorhandenen eForth-Befehlen_" 
wie  -> */, .r,  */mod,   .r   und   query

_z.B. wie in den Examples:_

Example 7  ->     : NT    ( nNT -- $ )    100 3055 */  ;
Example 11 ->    : year ( year --, compute Julian date and leap year )
               dup 1949 - 1461 4 */mod   ( days since 1/1/1949 )
Example 15 ->    : charakter ( n -- )   dup emit hex dup 3 .r
Example 17 ->   : getNumber ( -- n )
                               begin cr ." Geben Sie eine Nummer ein:" 
( Nachricht )
                               query bl word number?

Könnten Sie mir hier eventuell weiterhelfen? Ich wäre Ihnen sehr verbunden!

Vielleicht gibt es dafür Ersatz oder Umschreibebefehle?

vielen Dank für Ihre Bemühungen
mit freundlichen Grüßen

Peter Höhne

PS: falls sie die kpl. Examples sehen wollen, den Ordner mit den
FF-Examples hatte ich beigefügt
     das --> zip-File wurde aber nicht angenommen, kann es aber gern als
doc-File nachsende.

[Flashforth-devel] Atmega32 - flashforth

[Les N. <les...@sh...>]

Hi,

does anyone know if there is a Atmega32 hex file version available of 
Flashforth.


Thanks,

les

[Flashforth-devel] Latest Flashforth anomaly with >a and a> words

[Christian H. <hin...@ou...>]

Hi to the Flashforth support team.

In FlashForth 5 ATmega328 13.01.2019, I could do this:
  ok<#,ram>
$aabb >a  ok<#,ram>
a>  ok<#,ram> 43707
hex  ok<$,ram> aabb

In E FlashForth 5 ATmega328 13.06.2022, it cannot be done. Why?

 $aabb >a  ok<#,ram>
a>  ok<#,ram> 10812
hex  ok<$,ram> 2a3c
  ok<$,ram> 2a3c
I tried various older versions and FlashForth 5 ATmega328 13.01.2019
seems to be the last version that worked at the console interactively.
Why?
What was the purpose of >a and a>.
I used it for temporary storage to recall data in an ISR.
Did I misunderstand the use of the A register?
Where does the A register reside in the RAM memory space?
Why did it change?

Thanks for your help.

Christian Hinse

[Flashforth-devel] uflg ustatus USER variables

[Ed <dx...@gm...>]

These are byte-sized USER variables in FF.  Uflg is used by ACCEPT but ustatus appears to be unused.  What was the intended purpose of the latter?

Re: [Flashforth-devel] documentation

[Peter J. <pe...@me...>]

On 6/6/22 07:54, Brian K Navarette wrote:
> On the website the ff5-sheet pdf under the logic operators shows eor
> as the word for exclusive or when the word is xor.
> brian-in-ohio
>
>
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

Thanks Brian.  There are some slightly more recent PDF files at 
https://github.com/pajacobs-ghub/flashforth-docs

Better still, I have updated the documentation this past few months 
while converting it to Asciidoc.  The source files are in the repository 
mentioned above and the HTML rendering is at 
https://pajacobs-ghub.github.io/

Although the original LaTeX documents are good for paper-based 
references, there seems to be a preference for browser-based references 
that are easier to copy-paste.  Also, for these particular documents, I 
have found the AsciiDoc markup easier to work than the LaTeX markup.  I 
will leave the LaTeX and PDF files on github but prefer to update and 
maintain the AsciiDoc files.

Cheers,

Peter J.

[Flashforth-devel] documentation

[Brian K N. <bkn...@gm...>]

On the website the ff5-sheet pdf under the logic operators shows eor
as the word for exclusive or when the word is xor.
brian-in-ohio

Re: [Flashforth-devel] Transient definitions

[Ed <dx...@gm...>]

I’ve updated the code to make it more robust.  Previously the user
had to ensure a named definition was present immediately after
PERM.  That’s no longer necessary as one is created automatically.

\ Transient definitions.  Load TRANSient code in high memory
\ (e.g. assembler) and DISCARD when no longer needed.

2variable tlnk

: trans ( size -- )
  aligned  latest @  align ihere  tlnk 2!
  flash hi ram 1+ swap - [ latest #6 - ] literal ! ;

: perm ( -- )  tlnk cell+ @ [ latest #6 - ] literal !
  latest @ i, ihere $2001 i, latest ! \ dummy def for discard
;

: discard ( -- )  tlnk 2@ ! ;

\ example
$100 trans
: foo ;
perm
: bar ;
discard

[Flashforth-devel] Behead

[Ed <dx...@gm...>]

A utility to hide word names that are no longer needed

: name? ( name -- nfa )
  bl word latest @ (f) ?abort? c>n ;

: behead ( from to -- )
  name? name? 2dup u< if swap then 2- @ swap latest
  begin 2dup @ - while @ dup while 2- repeat then nip ! ;

\ demo
behead name? name?

[Flashforth-devel] Transient definitions

[Ed <dx...@gm...>]

The following allows one to use the assembler and discard it when done. Briefly tested on AVR FF dated 2021-11-28.

\ Transient definitions.  Load TRANSient code in high memory (e.g.
\ assembler) and DISCARD when no longer needed.  NOTE: For DISCARD
\ to work a named definition must immediately follow PERManent.

2variable tlnk

: trans ( size -- )
  aligned  latest @  align ihere  tlnk 2!
  flash hi ram 1+ swap - [ latest #6 - ] literal ! ;

: perm ( -- )  tlnk cell+ @ [ latest #6 - ] literal ! ;

: discard ( -- )  tlnk 2@ ! ;

\ usage
$100 trans
: foo ;
perm
: bar ;
discard

Re: [Flashforth-devel] UNO lockup

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

FYI 

-------- Original Message -------- 

 		SUBJECT:
 		RE: [Flashforth-devel] UNO lockup

 		DATE:
 		2022-03-27 05:46

 		FROM:
 		Ed <dx...@gm...>

 		TO:
 		Mikael Nordman <mik...@fl...>

Well, that seems to have done the trick! 

I can't say for how long I'd been using the wrong fuse value but it
wasn't a recent change.  Thanks for spotting it. 

Regarding brown-out trigger level, IIRC I chose the Arduino default. 
Thinking about it, it's probably the safer value for UNO/NANO boards as
these were designed to be able to run off USB power which translates to
a Vcc somewhat less than 5V. 

From: Mikael Nordman
Sent: Sunday, 27 March 2022 00:03
To: Ed
Subject: Re: [Flashforth-devel] UNO lockup 

At least you are using the wrong high fuse, it should be 0xdf for the
XC8 version. 

0xda is for the avrasm version. 

0xda ends up ( after NOPs) in  umstar0: 
which then makes a return that underflows the return stack. 

-- 
--
Mikael

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

There certainly seems to be an issue with CH340-based boards.  I googled but couldn’t find any reports of memory corruption.  Admittedly not every app will contain code that writes to flash, though writing to eeprom is common enough.  Not to worry.

Re: [Flashforth-devel] UNO lockup

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

As the problem occurs even when sufficient boot time is used,
I would still say that your problematic boards have some HW related
problem
that just happens to cause a problem with a particular code layout. 

As there are many boards that do not have a problem, the FF kernel
should be just fine. 

For example the Vcc filtering may be insufficient or some other problem.


The code version that works has the FF kernel code located in the end of
the flash.
The beginning of flash just has the interrupt vector table and then 20
Kbytes of NOP
until the kernel code begins. 

The problematic code has the FF kernel code located in the beginning of
the flash.
There possible erroneous code execution hits the kernel in a different
manner. 

BR Mikael 

On 2022-03-24 13:58, Ed wrote:

> On 2022-03-24 09:05, Mikael Nordman wrote: 
> 
>> 
> 
>> You could comment out the prompt code from QUIT and see if there is a difference. 
> 
> Tried the above edit for FF 2021-11-28 but it made no difference on the problematic 
> 
> 328 SMD boards.  Brownout fuse was set to $FC.  I waited 6 seconds between plugging 
> 
> USB cord in/out so as to not interrupt FF booting up but still it managed to corrupt 
> 
> the flash.  The terminal app was inactive so no KEY input from me. 
> 
>> The avrasm2 ff's  have more of the code in the bootloader section and I there may 
> 
>> be some logical differences also, but I have not checked further. 
> 
> FWIW the first XC8 version (dated 2021-03-29) worked ok on my problematic boards. 
> 
> It was the next release (2021-09-04) where things came unstuck.

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

On 2022-03-24 09:05, Mikael Nordman wrote:
> 
> You could comment out the prompt code from QUIT and see if there is a difference.

Tried the above edit for FF 2021-11-28 but it made no difference on the problematic
328 SMD boards.  Brownout fuse was set to $FC.  I waited 6 seconds between plugging
USB cord in/out so as to not interrupt FF booting up but still it managed to corrupt
the flash.  The terminal app was inactive so no KEY input from me.

> The avrasm2 ff's  have more of the code in the bootloader section and I there may
> be some logical differences also, but I have not checked further.

FWIW the first XC8 version (dated 2021-03-29) worked ok on my problematic boards.
It was the next release (2021-09-04) where things came unstuck.

Re: [Flashforth-devel] UNO lockup

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

After further testing my conclusion is that the rapid switching of Vcc
induces writes to
EEPROM, which may be corrupted by the sinking Vcc. 

Apparently playing with the Vcc can lead to undefined behaviour which
may cause
the eeprom or flash write code to be executed erroneously.
This is unfortunate as the non-brickable FF becomes brickable. 

So my recommendation is to not cut the power when a write to eeprom is
performed.
Normally there is a write to EEPROM just before OK is printed, if any of
the DPs, 
TURNKEY or the PROMPT values have changed in the RAM cache. 

The other recommendation is to activate the brownout detector at 4
volts. 

BR Mikael 

On 2022-03-24 09:05, Mikael Nordman wrote:

> I think the problems are  caused by corrupted eeprom contents.
> It gets corrupted when reading or writing at too low Vcc.
> Switching the Vcc on and off rapidly puts the chip in a state where the eeprom is corrupted.
> The prompt vector is fetched from eeprom and if it points to code writing to flash it can also corrupt the flash.
> Executing the prompt vector requires that a newline is received from the  UART, but I guess that
> could occur when playing with the Vcc. 
> 
> I did some further test with brownout disabled and added 100 ms delay in warm
> before reading or writing the eeprom. It seemed to make it more difficult to corrupt the eeprom
> but eventually it was corrupted anyway. That makes me think that when the power is switched
> off and a eeprom write occurs during a decaying Vcc, there will be corruptions.
> So a delay does not really help. 
> 
> When I add the brownout reset at 4 volts, the corruptions do not occur anymore on my board. 
> 
> The avrasm2 ff's  have more of the code in the bootloader section and I there may be some logical differences also, but I have not checked further. 
> 
> One change could be to keep the prompt vector in ram only. That would ensure it has a sane value in each startup.
> You could comment out the prompt code from QUIT and see if there is a difference. 
> 
> The difference between your boards is caused by the power supply and its filtering characteristics. 
> 
> BR Mikael 
> 
> On 2022-03-24 02:57, Ed wrote:
> 
>> Yes - the fuse value should be 0xFC - not 0xFD as I used for my tests. 
>> 
>> I tried the new fuse value on FF dated 2021-11-28 but still getting flash corruption on the two boards with the SMD 328 / CH340 chips. 
>> 
>> While I'd like to believe those boards are faulty in some way, they seem to work fine when using FF dated 2021-03-29 or earlier. 
>> 
>> From: Mikael Nordman
>> Sent: Thursday, 24 March 2022 06:20
>> To: fla...@li...
>> Subject: Re: [Flashforth-devel] UNO lockup 
>> 
>> I did some tests on my Arduino UNO board. 
>> 
>> If the brown out reset is disabled and I quickly do power on/off,  a lot of random flash and eeprom  errors occur. 
>> 
>> With the brown out reset enabled (any voltage), there are no errors. 
>> 
>> So it seems definitely recommended to have the brown detection enabled
>> Probably the 4.5 V value should be the safest value. Extended fuse = 0xFC on the Atmega 328. 
>> 
>> BR Mikael
> 
> -- 
> --
> Mikael 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] UNO lockup

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

I think the problems are  caused by corrupted eeprom contents.
It gets corrupted when reading or writing at too low Vcc.
Switching the Vcc on and off rapidly puts the chip in a state where the
eeprom is corrupted.
The prompt vector is fetched from eeprom and if it points to code
writing to flash it can also corrupt the flash.
Executing the prompt vector requires that a newline is received from the
 UART, but I guess that
could occur when playing with the Vcc. 

I did some further test with brownout disabled and added 100 ms delay in
warm
before reading or writing the eeprom. It seemed to make it more
difficult to corrupt the eeprom
but eventually it was corrupted anyway. That makes me think that when
the power is switched
off and a eeprom write occurs during a decaying Vcc, there will be
corruptions.
So a delay does not really help. 

When I add the brownout reset at 4 volts, the corruptions do not occur
anymore on my board. 

The avrasm2 ff's  have more of the code in the bootloader section and I
there may be some logical differences also, but I have not checked
further. 

One change could be to keep the prompt vector in ram only. That would
ensure it has a sane value in each startup.
You could comment out the prompt code from QUIT and see if there is a
difference. 

The difference between your boards is caused by the power supply and its
filtering characteristics. 

BR Mikael 

On 2022-03-24 02:57, Ed wrote:

> Yes - the fuse value should be 0xFC - not 0xFD as I used for my tests. 
> 
> I tried the new fuse value on FF dated 2021-11-28 but still getting flash corruption on the two boards with the SMD 328 / CH340 chips. 
> 
> While I'd like to believe those boards are faulty in some way, they seem to work fine when using FF dated 2021-03-29 or earlier. 
> 
> From: Mikael Nordman
> Sent: Thursday, 24 March 2022 06:20
> To: fla...@li...
> Subject: Re: [Flashforth-devel] UNO lockup 
> 
> I did some tests on my Arduino UNO board. 
> 
> If the brown out reset is disabled and I quickly do power on/off,  a lot of random flash and eeprom  errors occur. 
> 
> With the brown out reset enabled (any voltage), there are no errors. 
> 
> So it seems definitely recommended to have the brown detection enabled
> Probably the 4.5 V value should be the safest value. Extended fuse = 0xFC on the Atmega 328. 
> 
> BR Mikael

-- 
--
Mikael

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

Yes - the fuse value should be 0xFC – not 0xFD as I used for my tests.

I tried the new fuse value on FF dated 2021-11-28 but still getting flash corruption on the two boards with the SMD 328 / CH340 chips.

While I’d like to believe those boards are faulty in some way, they seem to work fine when using FF dated 2021-03-29 or earlier.


From: Mikael Nordman
Sent: Thursday, 24 March 2022 06:20
To: fla...@li...
Subject: Re: [Flashforth-devel] UNO lockup

I did some tests on my Arduino UNO board.
If the brown out reset is disabled and I quickly do power on/off,  a lot of random flash and eeprom  errors occur.
With the brown out reset enabled (any voltage), there are no errors.
So it seems definitely recommended to have the brown detection enabled
Probably the 4.5 V value should be the safest value. Extended fuse = 0xFC on the Atmega 328.
BR Mikael

Re: [Flashforth-devel] UNO lockup

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

I did some tests on my Arduino UNO board. 

If the brown out reset is disabled and I quickly do power on/off,  a lot
of random flash and eeprom  errors occur. 

With the brown out reset enabled (any voltage), there are no errors. 

So it seems definitely recommended to have the brown detection enabled
Probably the 4.5 V value should be the safest value. Extended fuse =
0xFC on the Atmega 328. 

BR Mikael 

On 2022-03-23 16:12, Mikael Nordman wrote:

> Ed, 
> 
> Setting the brown-out reset bits to %100 (4.3 volts) may prevent the corruption. 
> 
> From the datasheet: 
> 
> "A Flash program corruption can be caused by two situations when the voltage is too low. First, a regular write sequence to the Flash requires a minimum voltage to operate correctly. Secondly, the CPU itself can execute instructions incorrectly, if the supply voltage for executing instructions is too low." 
> 
> "Keep the AVR RESET active (low) during periods of insufficient power supply voltage.
> This can be done by enabling the internal Brown-out Detector (BOD) if the operating volt-
> age matches the detection level." 
> 
> BR Mikael 
> 
> On 2022-03-23 10:02, Ed wrote:
> 
>> I did some more testing involving more boards across several FF versions with no real conclusion.  Results attached. 
>> _______________________________________________
>> Flashforth-devel mailing list
>> Fla...@li...
>> https://lists.sourceforge.net/lists/listinfo/flashforth-devel
> 
> -- 
> --
> Mikael 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] UNO lockup

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

Ed, 

Setting the brown-out reset bits to %100 (4.3 volts) may prevent the
corruption. 

>From the datasheet: 

"A Flash program corruption can be caused by two situations when the
voltage is too low. First, a regular write sequence to the Flash
requires a minimum voltage to operate correctly. Secondly, the CPU
itself can execute instructions incorrectly, if the supply voltage for
executing instructions is too low." 

"Keep the AVR RESET active (low) during periods of insufficient power
supply voltage.
This can be done by enabling the internal Brown-out Detector (BOD) if
the operating volt-
age matches the detection level." 

BR Mikael 

On 2022-03-23 10:02, Ed wrote:

> I did some more testing involving more boards across several FF versions with no real conclusion.  Results attached. 
> _______________________________________________
> Flashforth-devel mailing list
> Fla...@li...
> https://lists.sourceforge.net/lists/listinfo/flashforth-devel

-- 
--
Mikael

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

I did some more testing involving more boards across several FF versions with no real conclusion.  Results attached.

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

Beginning to look like it may be a defective UNO so false alarm. 

Re: [Flashforth-devel] UNO lockup

[Ed <dx...@gm...>]

I dumped the offending UNO (see attachments).  It shows several holes in the image of 128 bytes each where the flash had been written with zeros.  Then I remembered I likely still had the USBtinyISP programmer connected to the UNO as the PC powered down.  Anyway it gives me a few more things to test/exclude.

Re: [Flashforth-devel] Alignment in comma-quote

[Ed <dx...@gm...>]

Ah.  These microcontrollers certainly make it hard to save bytes :(