Short version
After exactly ten years in service our GTN750 showed an interesting sporadic malfunction: it just froze in flight. We had three occurrences of this behavior in total.
The good thing about the whole story is that I called our avionics shop and they said if you’re AOG or it’s otherwise urgent, we’ve a loaner device we can immediately send out to you. We didn’t need that and in the end Garmin seem to have a flat rate for repairs of around 1600 Euros what isn’t that much of a disaster in aviation. After a little over two weeks the unit is back in service, so this is the end of the short version of the story.
Nerdy version tl;dr
I could find almost nothing abut a failure like this on the internet. Moreover, the guys at our avionics shop could only remember one remotely similar occurrence which was related to an interfaced weather radar. The whole behavior also raises questions about the architecture of these devices, so here is the longer story:
Symptom: GTN750 freezes in flight (happened 3 times)
After recycling in flight:
I could read out the error log of the device and there was one record that might correlate to one event but without deep understanding of the architecture and access to the source code this is of no help and it’s highly uncertain. Interestingly they seem to have assertions in the production code. Anyway, I learned from path names in the error log that a Unix-like OS is apparently used.
My guess is, that the terrain database is stored in some sort of nv memory that is accessed as a block device by the OS. Either due to a data inconstancy or, more likely, a HW defect this device could not be accessed under certain circumstances and therefore the GTN froze. However, this is just a guess.
I was amazed that this can happen at all. I don’t understand why there is no watchdog in such a system, that prevents it from completely freezing indefinitely. Or is it poorly implemented?
I’m pretty sure Garmin’s repair was to replace the main board, as on reinstall the complete configuration and all databases were gone. I don’t really know though, as the documentation just says ‘repaired’ what is a bit underwhelming.
In conclusion I would say things can and will break even if they shouldn’t so I’m not too disappointed. For ten years I’ve been very happy with the 750 and I still am. A little more transparency from Garmin would have been nice and a few doubts about the architecture remain.
Calculating the price of an installed 750 it should last longer than 10 years.
In particular as we don’t fly 10.000 hours per year.
None of that is surprising.
They prob99 have a flash filesystem, using some FAT library (I use FatFS for my projects, to turn a 2MB FLASH into a FAT12 logical drive).
Having asserts in the code is a bit weird unless these are used to write error messages to a file, but most asserts are used to pick up critical errors (e.g. an invalid parameter to a function) and by the time you get one of those, the whole box is of not much use.
FLASH has a finite write endurance. One can implement various strategies but in the end it will run out.
There could be an intermittent fault, explaining why repeated power cycling makes a database appear or not.
Garmin will never publish anything which enables detailed speculation about the architecture. Some people have worked it out to varying extents and this has enabled various hacks to enable software options. Garmin obviously know about this.
Most if not all avionics does not have a watchdog. To an embedded dev this may seem totally weird but I guess somebody made the decision that the certified box, software written to DO-178B or whatever, is by definition perfect and cannot crash 
This can be a valid argument if there is an RTOS (which there will be) and preserving some low level critical task (e.g. autopilot) is more important than preserving something with a user / display interface, whereas a watchdog would reset the whole lot and do it in a very visible way. But also watchdogs are not 100% immune from bugs, and this can be unintended wdog resets (masking a crashed program) or code which works but fails to reset the watchdog in some narrow circumstances and will thus trip a working unit. You can argue this both ways. I am currently finishing a customer-programmable box on which using the watchdog is optional.
And as I often say, a lack of problem reports online is not itself surprising because practically everybody with this box in the panel will be first and foremost looking after his relationship with the Garmin dealer. You simply cannot afford to p1ss him off. I have long lost count of reports like this where authorisation to post it was refused for precisely the reasons I give.
Now I understand why the former owner of my plane wanted two totally independent devices each with GPS, NAV, ILS and COM features
FLASH has a finite write endurance. One can implement various strategies but in the end it will run out.
I thought about that too but I don’t think it’s plausible as the terrain database is almost never updated. If it was a non-local effect it would influence other data as well.
Having asserts in the code is a bit weird unless these are used to write error messages to a file, but most asserts are used to pick up critical errors (e.g. an invalid parameter to a function) and by the time you get one of those, the whole box is of not much use.
Asserts are macros that expand empty in the production version of the code. Normally they only expand to a conditional error message (and termination) in the debug version. Similar constructs that remain in production code are usually called guarantees.
They prob99 have a flash filesystem, using some FAT library (I use FatFS for my projects, to turn a 2MB FLASH into a FAT12 logical drive).
I don’t think they use a library and otherwise run on bare metal. I even doubt they use an RTOS. From the register dumps you can see that it is an AMD64 CPU and UNIX-like pathnames are used, so it might well be Linux.
And as I often say, a lack of problem reports online is not itself surprising because practically everybody with this box in the panel will be first and foremost looking after his relationship with the Garmin dealer. You simply cannot afford to p1ss him off. I have long lost count of reports like this where authorisation to post it was refused for precisely the reasons I give.
Why would that be? What else could our shop have done? They immediately offered to send loaner device. They already did that when we were stuck in Greenland with a broken KI256 years ago. I can’t see why being helpful would be bad PR for them.
