Losing device after upgrade from 7.0.0.3 to 7.0.0.5 #6961
Assignees
Labels
bug
Type - Confirmated Bug
Requires more research (devs)
Action - Issue requires more research
workaround
Result - The work on the issue has ended with an alternative solution
Comments
|
I found the issue: Setting @arendst I don't know why |
s-hadinger
pushed a commit
to s-hadinger/Tasmota
that referenced
this issue
Nov 18, 2019
6 tasks
s-hadinger
changed the title
arendst
added a commit
that referenced
this issue
Nov 19, 2019
Fix check deepsleep for valid values in Settings (#6961)
arendst
added a commit
that referenced
this issue
Nov 19, 2019
Fix unwanted deep sleep initiation (#6961)
|
I've done some testing and still cannot explain why Settings.deepsleep is 0xFFFFFFFF in this case.
Tasmota-minimal should not change any value in the Settings. Loading Tasmota 7.0.0.5 should not change any value in Settings too. I'm a bit eary that apart from Settings.deepsleep being 0xFF there might be more settings set wrong. In my testing using the debug code allowing me to dump settings area in different stages the settings perform as expected. Anyway. I updated your PR with what I think does the same as your solution while adding an extra test to not enable deepsleep unwantingly. Thx again for your self-supporting solution. |
|
EUREKA!!!! I know from my EspEasy friend TDer they had issues with certain flash chips. I never noticed it with Tasmota but this time I think we hit the hammer. Chips manufactered by Puya need a special write operation where a flash sector needs to be read first before it can be succesfullt written. I think that's where this goes wrong. Your flashchip id is "FlashChipId":"146085". The 0x85 is the TUYA manufacturer ID. I also noted that the core guys did add some code in pre-2.6.0 with regards to this PUYA chip initiated again by TDer. For some reason it failed on you but I will dive in deeper and see where it hurts. Nice issue. I'll reopen for now. |
arendst
added
bug
|
@arendst needs PUYA support to be enabled? |
|
Analysis of the current core versions pre-2.6.0 and up show that the PUYA code is already enabled by default. See file Esp.cpp: Using the below platformio compile time directive we have control over PUYA_SUPPORT. Without the parameter the code size is the same as with parameter Disable PUYA_SUPPORT with Why it then still failed I'm not sure but perhaps the buffer size of just 256 bytes is causing issues. For someone having access to a PUYA flash development system it would be an option to execute the following commands with either the default buffer size of 256 bytes or the full needed flash page size of 4096 bytes. Note also that on systems with TUYA flash this PUYA_BUFFER will be permanently decreasing your RAM size by 4k as it is to be expected that the flash hardware won't chage on the fly ;-) Test sequence:
|
|
How do I know if I have a PUYA flash? I will try the above tonight. |
|
@s-hadinger Your flashchip id is "FlashChipId":"146085". The 0x85 |
|
So it is a Puya flash |
|
I am completely in the dark... I disabled PUYA: Before Reset: After So no issue shown here. I also upgrade a Lohas bulb from the same batch I previously flashed and that should have the same issue, no luck (without new Reset): Is it possible that the problem happens only at Power Up and not with Reset which only does a restart? |
|
I also did a serial flash erase, then flashed with a non-PUYA firmware, and power down. I did a full power-up, Wifi configuration and I have no idea how DeepSleepTime was set to 0xFFFFFFFF, but it still happened twice... |
|
Last try, I took another bulb from tuya-conver, flashed directly a test with debug enabled, and here are the values (correct and same as before)... |
|
I don't dare to ask but if you do the upgrade again from 7.0.0.4 via minimal 6.7.1 to 7.0.0.5 does it work now? |
|
BTW the two failing ones were they both tuya flash chips? |
|
Yes, the two failing bulbs where from different brands (Lohas and XMRJ), both PUYA (FlashId ending with 85). I just tried tuya-convert on a brand new LOHAS, and upgrading from tuya's 7.0.0.3 to 7.0.0.5 with debug enabled: no issue. Then I now have a wifi issue, but I'll dig a little and may open a new issue... Maybe linked to 2.6.1. |
|
Oops, sorry the Lohas chipid is 1440C8 so not PUYA. It may have been a different issue after all, and all the tests above are irrelevant. I need to redo it on the other bulb... |
Try 2.6.1 with SDK: SDK22x_190703. Then do a reset 3 and de-energize it and energize it again. Also reboot your router to be in a 100% clean start. |
|
I'm now pretty sure I had two distinct issues:
I need to redo all PUYA tests tomorrow on the XMRJ bulb, and try changing the SDK on the LOHAS. |
|
Congrats for your tenacity. I have wifi issues too on low RSSI devices and will also start using SDK22x_190703 on them now. |
|
@Th0maz Thanks, I will try. Although my bulbs don't use software PWM, but the symptoms are indeed the same. |
|
@s-hadinger I believe in @Th0maz 's case its purely the PWM setting sleep to 0 which was causing issues due to the device not having sufficient thermal disipation similar to what we experienced with the sonoff basic R1's. The |
|
@Th0maz @andrethomas Brilliant! Right on the spot! This was indeed the issue on my Lohas bulb as well. The issue was too fast to be a thermal issue, I guess having Now the next question is why does I'm willing to change |
s-hadinger
pushed a commit
to s-hadinger/Tasmota
that referenced
this issue
Nov 20, 2019
6 tasks
|
I tried a @arendst I think I now understand what happened. Two completely unrelated issues with very similar symptoms - bad luck. The XMRJ bulb with PUYA flash was tuya-converted a while ago, and the version maybe did not contain the PUYA code at that time. DeepSleep was not activated in my firmware until I flashed a 7.0.0.4 with DeepSleep activated, hence the freeze. The LOHAS bulb was a Thanks for all your help! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
BUG DESCRIPTION
A clear and concise description of what the bug is.
@arendst This is the second bulb I fail to upgrade with a similar scenario. Is it possible that DeepSleep gets activated by mistake?
Wifi comes up for 5 seconds then it is lost until next reboot.
I found the following weird messages in logs:
and
Here is the complete
WebLog 4until I lose connectivity:REQUESTED INFORMATION
Configuration output here:
STATUS 0 output here:
Console output here:
The text was updated successfully, but these errors were encountered: