Has anyone tracked down the problem with battery devices that become bricked after the batteries drain? I've seen it mentioned but I can't remember where I saw the information and I'm not using the right search to find it.
I just had it happen to my non-TuyaMCU door sensor. Unfortunately, I didn't save a backup of the FUBAR'd firmware before erasing it. I did hook it up the serial log and saw:
From this I assumed either the flash Vars or flash CFG had become corrupted. For my device I rewrote the flash vars code to be a little better in how it stores and finds the latest stuff on boot. During this I did think of two solutions that people might benefit from.
The first is a simple one, after the device registers enough failed boots to trigger RESTARTS_REQUIRED_FOR_SAFE_MODE stop writing to the flash. I did a quick test with some "dead" AAA batteries (~1v each). The device boots and reboots hundreds of times a minute. When I hooked it back up to a power supply, I noticed the device was writing to the flash each boot. With your current implementation that means the flash is being hammered with updates when the device has low batteries. Thousands of writes an hour, etc.
The second is to NOT write to the flash until "####### Set Boot Complete #######" has been reached. This is a little more complicated and of course there is an exception for the boot counter (which is capped at RESTARTS_REQUIRED_FOR_SAFE_MODE ), but it works well for me. For the CFG it doesn't require a lot of extra coding. I added a safe to write flag and it is tripped after the boot is marked complete or when you exit safe mode which causes a CFG_Save_IfThereArePendingChanges and any stored changes are written. The vars was a bit more complicated. The firmware potentially writes when reading, reads (with potential writes) and explicitly writes all over the place. I suggest a simple rule don't write on a read, ever. Still it's not too bad because the channel changes can get written to memory and when the boot is marked complete all the channel information is written to flash anyway. So I just stop writing (except boot count) while in the "boot" phase.
I just had it happen to my non-TuyaMCU door sensor. Unfortunately, I didn't save a backup of the FUBAR'd firmware before erasing it. I did hook it up the serial log and saw:
V:BK7231N_1.0.1
REG:cpsr spsr r13 r14
SVC:000000D3 00401C1C 000033AC
IRQ:000000d2 00000010 00401e0c 3ffff7f5
FIR:000000d1 00000010 00401ffc 77ff856f
SYS:000000df 0040192c 00000158
ST:00000003
J 0x10000
bk_misc_init_start_type 3 3
prvHeapInit-start addr:0x412bb8, size:119880
[Flash]id:0x1c7015
sctrl_sta_ps_init
cset:0 0 0 0
OpenBK7231N, version DoorSensors_88af71253b87_doorsensor
Entering initLog()...
Commands registered!
initLog() done!
Info:GEN:0 - Main_Init_Before_Delay
From this I assumed either the flash Vars or flash CFG had become corrupted. For my device I rewrote the flash vars code to be a little better in how it stores and finds the latest stuff on boot. During this I did think of two solutions that people might benefit from.
The first is a simple one, after the device registers enough failed boots to trigger RESTARTS_REQUIRED_FOR_SAFE_MODE stop writing to the flash. I did a quick test with some "dead" AAA batteries (~1v each). The device boots and reboots hundreds of times a minute. When I hooked it back up to a power supply, I noticed the device was writing to the flash each boot. With your current implementation that means the flash is being hammered with updates when the device has low batteries. Thousands of writes an hour, etc.
The second is to NOT write to the flash until "####### Set Boot Complete #######" has been reached. This is a little more complicated and of course there is an exception for the boot counter (which is capped at RESTARTS_REQUIRED_FOR_SAFE_MODE ), but it works well for me. For the CFG it doesn't require a lot of extra coding. I added a safe to write flag and it is tripped after the boot is marked complete or when you exit safe mode which causes a CFG_Save_IfThereArePendingChanges and any stored changes are written. The vars was a bit more complicated. The firmware potentially writes when reading, reads (with potential writes) and explicitly writes all over the place. I suggest a simple rule don't write on a read, ever. Still it's not too bad because the channel changes can get written to memory and when the boot is marked complete all the channel information is written to flash anyway. So I just stop writing (except boot count) while in the "boot" phase.
