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