Garmin MFD + Raymarine ST60 Runtime Crash

[Alita49DS]

This is one from those who are into binary code.

I have a Garmin 751xs MFD. If reads the Seatalk output from the Raymarine ST60 instruments converted to NMEA 0183 via an ES8001 convertor. Usually it all works. Including being able to use the ST6001 Raymarine autopilot to track a GoTo set on the Garmin MFD. At other times the MFD will simply crash. And crash again and again. If one turns off the Raymarine instruments it is stable.

The Garmin logs show the following: -



Any ideas from the attached screen shots what is causing the crash?

As I wrote in the B&G thread recently, it amazes me that the OS (operating system) on these things is not sand boxed as one now has come to expect with a PC. A black screen of death because of a one line software conflict somewhere is simply unacceptable.

[Alita49DS]

In case you cannot see the link it is

https://1drv.ms/u/s!AqLwtI1czSAllOY6...pMNgQ?e=kHk74B

Why on earth it is so hard to attach a photo I have no idea.

[smac999]

I have never seen a Garmin crash.

I have hooked lots up to st 60 gauges but I always use the E22158 And convert the st60 to nmea 2000

[LongRange]

According to this, there is a 6.80 version of the software for that unit, as opposed to 6.60 which is shown in your screenshots.

I suggest upgrading to 6.80 and keeping your fingers crossed during the process, because Garmin will presumably not be releasing anything newer for a discontinued product.

The crash info will not mean much to anyone who is not extremely familiar with the internals of Garmin software. It is an ARM processor, going by the 16 general purpose (GP) registers and the Current Program Status Register (cpsr) - equivalent to the EFLAGS register on IA-32.

Searching by the cpsr, 0x6e5d8024, you are not the first to be in this place with Garmin units. Anecdotally, its a GPS runtime library (RTL) which is ironically the very first thing I blamed for a hypothetical crash caused by a third-party library, over on my own thread

The GP registers show a mix of memory pointers (the big numbers) and various integers and local variables (small numbers), but without access to the source code or at least an attached debugger it confers virtually no diagnostically useful information.

Assuming the hardware is fine and it is a software problem, the fix is always going to be contained in a software update, and the workaround is to avoid traversing that bit of code, which you do by disconnecting the ST60s.

I hope the 6.80 upgrade does something useful for you.

[Alita49DS]

Thank you very much Cruisers & Sailing Forums - View Profile: LongRange

I have religiously downloaded the Garmin updates in the past and they have done absolutely nothing to resolve the problem.

What is really useful in your post is your identification of the RTL Trap as related to GPS. The Garmin unit has a built in GPS. The Raymarine units have their own GPS.

I am now in England and the boat is in Genoa but it may be that if I were to go into the Garmin settings and seek to exclude the Raymarine GPS sentences from the NMEA that the Garmin reads I could kill the error.

The other linked unit which has GPS is the Simrad AIS but that is on the other NMEA port with a different baud rate and when the Garmin and that are on at the same time I have never had an error.

I have now looked on the internet under 0x6e5d8024 but cannot find anything.

[LongRange]

Originally Posted by Alita49DS

Thank you very much Cruisers & Sailing Forums - View Profile: LongRange

I have religiously downloaded the Garmin updates in the past and they have done absolutely nothing to resolve the problem.

What is really useful in your post is your identification of the RTL Trap as related to GPS. The Garmin unit has a built in GPS. The Raymarine units have their own GPS.

I am now in England and the boat is in Genoa but it may be that if I were to go into the Garmin settings and seek to exclude the Raymarine GPS sentences from the NMEA that the Garmin reads I could kill the error.

The other linked unit which has GPS is the Simrad AIS but that is on the other NMEA port with a different baud rate and when the Garmin and that are on at the same time I have never had an error.

I have now looked on the internet under 0x6e5d8024 but cannot find anything.

I'd still suggest applying 6.80, just in case. The fact that past updates have not resolved the issue doesn't mean no updates will ever help.

If you search for 6e5d8024, without the leading 0x radix (which simply means what follows is a hexadecimal number), there are a few non-boaty forum posts about Garmin units rebooting due to GPS RTL crashes. That anecdotal info is my only reason for mentioning GPS. The anecdotes could be wrong, or 6e5d8024 could be a very generic Garmin number that is part of an exception/crash handler routine, and thus tends to feature in the majority of these debug logs.

I think it makes sense to exclude as much telemetry from the Raymarine units as possible, in the hope of systematically finding the problem area, or even bypassing the issue altogether.

[Alita49DS]

Again, thank you.

I have written to Garmin Europe and will see what they say about it.

Also, at the back of the manual for the 751xs there is a list of the NMEA0183 sentences that the Garmin transmits and receives. I will try and isolate.

However, the problem with isolation is that the fault is intermittent. At times the unit will stay up for days on end and then all of a sudden persistently crash. Hence my desire for a clue from the hex.

What would have been even better would have been an ability to save the fault log to a file on an inserted SD card. Again, Garmin do not provide that and it is all so sloppy and dated as an approach.

I have also downloaded the 6.80 file. Someone will explain to me why Garmin cannot break that down by relevancy so that one does not have to download 358MB. The file covers a plethora of devices. On a boat one is likely to have to use a connection with a limited data allowance.

Marine electronics are a clear candidate to be part of the Internet of Things (IoT). They should be able to update OTA (over the air). They should include on line fault reporting that includes the fault log sent "home" so the manufacturer can rectify and improve. The chart updates should also be OTA.

They do not even need to include a dedicated SIM as a WiFi chip is peanuts and they could tether.

There is so much that could be done yet they are primitive in comparison to an Android phone (mine is even just as water resistant) costing a fraction of the price.

Hopefully Garmin will read this week's Economist all about IoT and wake up.

[CaptTom]

Originally Posted by Alita49DS

Hopefully Garmin will read this week's Economist all about IoT and wake up.

Garmin will read it and laugh. Those suckers! Don't they know they can squeeze MUCH more out of their customers? Never waste money coding updates for anything more than 18 months old! Don't bother fixing bugs, or making your product serviceable. Just sell them a new unit. And make sure it costs about $2000US.

Come to think of it, Apple does a pretty good job of following the Garmin model.

[LongRange]

As I write this on my Android phone, there is a gaping hole in the pod above the cockpit table where my B&G Zeus3 normally resides. The unit has been handed over to the local B&G rep, and I am waiting to hear back from them. I thus very much relate to the frustration.

Perhaps the market for boaty electronics is simply too small to sustain the consumer desire for MFDs which match contemporary levels of software sophistication in phones and PCs. I'm in a marina that's a stone's throw from Athens, one of the world's premier cruising grounds, and around here there are maybe a million people who own an Android phone. I expect B&G would be struggling to count a thousand Zeus units in the same area.