If this is a consistent pattern that you’re observing (works well for the first several weeks then starts acting flaky), I wonder if this may have to do with manufacturing tolerances or not. For example, if Oticon has decided to start loosening up their mfg tolerance requirement more recently and don’t bin as many parts (which don’t meet stricter tolerances but meet looser tolerances) as they should. Then over time, the degradation of performance due to the wear and tear of usage starts to trip up the aids and causing more frequent reboots. One possibility is that the memories used inside the aids may start faulting here and there and those faulty spots in the memories get blocked off one by one to disallow use of them. Maybe eventually too many get blacked out that there’s not enough memory space left to support the normal operation. Whenever an overflow condition occurs (maybe a lot more data get sampled and stacked up more than usual, maybe in a difficult listening environment), because there’s not enough memory space to hold data for the computation, the aids are forced to reboot themselves to clear everything out to start anew.
Of course this is only a very wild guess from the over-imagination of an engineer here and this speculation may not be true at all. But if this random reboot consistently starts very infrequently in the beginning but more and more frequent as time goes on, then it’s a plausible explanation.
It’s also possible that it’s a firmware bug where there are memory leaks due to sloppy codes that would cause memories to get unnecessarily filled up and not cleared out when the computations are done, causing the memories to overflow to a point of forcing a restart. But if it’s a firmware sloppy bug, then it would affect more people across the board and there would have been more complaints than usual.