Thread: [Flashforth-devel] UNO lockup
Brought to you by:
oh2aun
Menu
▾
▴
flashforth-devel
|
From: Ed <dx...@gm...> - 2022-02-23 00:50:49
|
I find UNO with FF often locks up after PC has gone to sleep or powered down but still connected. Usually the result is no comms and reset doesn’t work. Seems to happen only after I’ve compiled a few simple definitions. Any ideas? p.s. It just came to me that I was powering the board via the USB. Would that be an issue? |
|
From: Mikael N. <mik...@fl...> - 2022-02-23 05:25:12
|
That sounds like the USB-to-serial converter on the UNO does not handle the USB protocol correctly. Since that converter is a separate chip on the board, I cannot understand how FF could be the problem. Pressing the reset button only resets the Atmega328 and FF, not the USB-serial converter. That is also an indication that the USB-serial converter has a problem. On 2022-02-23 02:50, Ed wrote: > I find UNO with FF often locks up after PC has gone to sleep or powered > down but still connected. Usually the result is no comms and reset > doesn't work. Seems to happen only after I've compiled a few simple > definitions. > > Any ideas? > > p.s. It just came to me that I was powering the board via the USB. > Would that be an issue? |
|
From: Ed <dx...@gm...> - 2022-02-23 06:05:43
Attachments:
ff5dump.txt
ff5org.txt
|
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. |
|
From: Ed <dx...@gm...> - 2022-02-23 14:35:14
|
Beginning to look like it may be a defective UNO so false alarm. |
|
From: Ed <dx...@gm...> - 2022-03-23 08:02:33
Attachments:
UNO_lockup.txt
|
I did some more testing involving more boards across several FF versions with no real conclusion. Results attached. |
|
From: Mikael N. <mik...@fl...> - 2022-03-23 15:20:40
|
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 |
|
From: Mikael N. <mik...@fl...> - 2022-03-23 19:19:08
|
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 |
|
From: Ed <dx...@gm...> - 2022-03-24 01:06:25
|
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 |
|
From: Mikael N. <mik...@fl...> - 2022-03-24 07:05:35
|
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 |
|
From: Mikael N. <mik...@fl...> - 2022-03-24 11:04:12
|
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 |
|
From: Ed <dx...@gm...> - 2022-03-24 11:58:34
|
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. |
|
From: Mikael N. <mik...@fl...> - 2022-03-24 16:38:51
|
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. |
|
From: Ed <dx...@gm...> - 2022-03-25 06:09:14
|
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. |
|
From: Mikael N. <mik...@fl...> - 2022-03-28 08:29:12
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X