Since we are having fun speculating:
If it were code that I had written, I would first look for possible out of bounds memory access, memory use after free, uninitialized memory, integer overflow, and uninitialized pointers. Such bugs often do not give predictable or repeatable symptoms.
If the code were written in C or C++, then there are very good tools available for finding such bugs. By compiling with both gcc and clang with all warnings enabled, then such bugs can often be found in the warning messages. Code review, although costly and time consuming, also often works for any programming language. https://en.wikipedia.org/wiki/Code_review
I would not use a language that does garbage correction memory management for software that needs to be low latency or "real-time". Garbage collection makes it impossible to predict latency which may sometimes be so long as to be described as "lockup". https://researcher.watson.ibm.com/researcher/view_page.php?id=7236
If I could not find the bug in my code, then I might play "blame the hardware engineer" and claim that one of the components was especially temperature sensitive and either needed to be clocked slower or cooled better. Or I might claim that there was too much capacitance on a particular trace.
I have had unexpected behavior after a firmware upgrade on my EOS R5 until I had removed and replaced the battery and when using 3rd party telephoto extenders. This has been rare and I have not blamed it on the firmware version. However, it appears to me that not every data structure is re-initialized during the automatic restart after a firmware upgrade and this could lead to memory corruption if the size of a data structure had changed.
I am speculating again.
If a memory corruption bug were fixed in the latest firmware update and not all data structures were re-initialized, then those corrupted data structures might cause the lockup whenever they are used. .
This is speculation, not advice, but I hope it might be useful to someone.
Canon reported fixing a bug that causes lockups. It might not be the only bug that causes lockups, but even if it were the only bug that causes lockups then the lockups might continue after the bug fix if the bug had corrupted some data structures that were not then reinitialized. A data structure is an abstraction used by software engineers to understand storage of information.
From my experience writing firmware, a firmware bug that causes lockups might corrupt data structures. The engineer who fixed the bug might not have any way of knowing which data structures had been corrupted. If the corrupted data structures are not re-initialized, then they could continue to cause lockups after the bug has been fixed. A reason not to reinitialize everything is to present the user with a camera that appears to have the same settings after the firmware upgrade as it had before.
One way that a user experiencing lockups could force reinitialization of at least some data structures in the firmware chip would be to:
- save settings
- reset to factory defaults
- reload settings if one assumes no bug in settings load, else enter settings through the menus
Some evidence that data structures were in fact corrupted is that after I updated my EOS R5 from 1.5.0 to 1.5.1, my C3 viewfinder information was weird, but was returned to normal by switching to C2 and then back to C3 which I speculated would also have caused some data structures to be reinitialized. If I were writing the code, then the C1, C2, and C3 settings would be stored in a data structure.
In summary, if there had been a firmware bug then it is plausible that some random fraction of users would continue to experience lockups through no fault of their own. It is plausible that in a system this complex that a software engineer would have no way of determining what needed to be reinitialized and would not want to reinitialize everything in order to preserve user settings.
I hope this might be helpful.
