That’s correct. Using JTAG to reset the DCT area will fix the problem. Yes, 0.4.2 and later fixes the issue.
For anyone curious about the technical details of the problem:
-
the device configuration table (DCT) holds WiFi crednetials and system flags. It is stored in a pair of 16Kbyte flash pages at 0x8004000 and 0x8008000
-
we are seeing occasionally bits set to 0 in an area that should otherwise be clear (0xFF)
-
the WICED DCT code only erases a flash page by looking at a small header. If the header is clean then it doesn’t erase the page, even when the page contains some 0 bits that should be reset to 1 with a page erase.
-
When writing to the DCT, data is written in chunks, and the DCT code in WICED reads back the chunk to verify it. Since there were some 0 bits already in the page, the written contents will always have 0 bits there, even if the intended value was a 1. This is due to how flash works. The data read back doesn’t match the data expected so the write function fails and the subsequent blocks of configuration data isn’t saved.
-
In short, the majority of the DCT becomes unmodifiable - frozen in it’s current state.
-
During a factory reset, a flag is set to indicate to the reset of the system to perform a factory reset. If the DCT becomes unmodifiable then, it’s not possible to reset the flag, and the device enters a continual factory reset loop.
The fix present in 0.4.2 and later is to alter the WICED DCT code to inspect the entire flash page to determine if it needs erasing. This ensures the page data is written as intended, and the full DCT page written without error.