DataField - System Error - Failed to Invoke <symbol> on Initialize

I am getting a System Error when trying to createField on initialize (to add FIT contributor). Error only happens on some devices (like Fenix7)

Error: System Error
Details: 'Failed invoking <symbol>'
Time: 2022-05-19T14:38:19Z
Part-Number: 006-B3907-00
Firmware-Version: '8.21'
Language-Code: eng
ConnectIQ-Version: 4.0.10
Filename: C5I65603

The stack trace indicates the error is happening on the first createField call.

 function initialize(dataField) {
        try {
            mCurrentInclineField = dataField.createField("inclineRunn", INCLINE_FIELD_ID, FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_RECORD_GRADE, :mesgType=>FitContributor.MESG_TYPE_RECORD, :units=>"%" });
            mTotalAscentLapField = dataField.createField("total_ascent", TOTAL_ASCENT_LAP_FIELD , FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_LAP_TOTAL_ASCENT , :mesgType=>FitContributor.MESG_TYPE_LAP, :units=>"m" });
            mTotalAscentSessionField = dataField.createField("total_ascent", TOTAL_ASCENT_SESSION_FIELD , FitContributor.DATA_TYPE_FLOAT, {:nativeNum=>NATIVE_NUM_FIT_SESSION_TOTAL_ASCENT, :mesgType=>FitContributor.MESG_TYPE_SESSION, :units=>"m" });
            mTotalDescentLapField = dataField.createField("total_descent", TOTAL_DESCENT_LAP_FIELD , FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_LAP_TOTAL_DESCENT , :mesgType=>FitContributor.MESG_TYPE_LAP, :units=>"m" });
            mTotalDescentSessionField = dataField.createField("total_descent", TOTAL_DESCENT_SESSION_FIELD , FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_SESSION_TOTAL_DESCENT, :mesgType=>FitContributor.MESG_TYPE_SESSION, :units=>"m" });
    
            mTotalDistanceLapField = dataField.createField("total_distance", TOTAL_DISTANCE_LAP_FIELD , FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_LAP_TOTAL_DISTANCE , :mesgType=>FitContributor.MESG_TYPE_LAP, :units=>"m" });
            mTotalDistanceSessionField = dataField.createField("total_distance", TOTAL_DISTANCE_SESSION_FIELD , FitContributor.DATA_TYPE_FLOAT, { :nativeNum=>NATIVE_NUM_FIT_SESSION_TOTAL_DISTANCE, :mesgType=>FitContributor.MESG_TYPE_SESSION, :units=>"m" });
            mCurrentInclineField.setData(0);
            mTotalAscentLapField.setData(0);
            mTotalAscentSessionField.setData(0);
            mTotalAscentLapField.setData(0);
            mTotalAscentSessionField.setData(0);
            mTotalDescentSessionField.setData(0);
            mTotalDescentLapField.setData(0);
        }
        catch(exception) {
             System.println("FIT Init Exception " + exception);
        }

    }

Runs fine in the emulator for all devices.

Anyone have any ideas?

Top Replies

FlowState 9 months ago in reply to SpitRider +1

SpitRider said:
However, in ERA I see a lot of "System Error" issues for other users. But what is really strange - these errors point not to the first line with FIT field creation but to the field…
FlowState 9 months ago in reply to jim_m_58 +1

jim_m_58 said:
On watches where you can only have 2 CIQ DFs in an activity, if every DF used less than 1/2 of the possible fields, that would be a work around.

Not to state the obvious, but that only works…

All Replies

FlowState 9 months ago in reply to jim_m_58

jim_m_58 said:
On watches where you can only have 2 CIQ DFs in an activity, if every DF used less than 1/2 of the possible fields, that would be a work around.

Not to state the obvious, but that only works if everyone is aware of the limit and is willing to play along (hence the other comment about game theory.)

Besides, "it's more complex than that". As noted in the thread that was linked, the limit is something like 16 RECORD fields and 22 fields of any type (RECORD, SESSION and LAP), and it can vary by device. (To be fair it will probably be the same for all devices which have a 2 field limit.)

So a dev could say "ok I'll create no more than 8 record fields, and no more than 3 session and lap fields." Except the dev has no way of knowing whether there's some additional, separate constraints on the number of session fields and the number of lap fields. And it doesn't help if even one other popular app decides not to play nice.

Furthermore, for most applications, if you record a record field, you also want to record a lap field. So you're either going to limit yourself to 3 record fields (or less), or forgo recording some of the lap fields that would naturally go along with your record fields.

Anyway I checked a recent activity and Stryd Zones records at least 9 different record fields. It should also record at least one lap field - it didn't in the activity I checked - not sure if that's due to a Stryd change or a firmware bug (there has been some recent discussion about bugs with FIT recording.)

Unsurprisingly, Stryd support asks users not to install any other Connect IQ data fields. So much for playing nice and being respectful of other devs. You think a company like stryd cares about whether a niche field from RandomIndieDev2001 will work in tandem with their field or not?

https://help.stryd.com/en/articles/8981619-stryd-zones-data-fields-faq

3. Do not install any other data fields other than Stryd Zones. Other Connect IQ apps and data fields may interfere with Stryd Zones

jim_m_58 said:
It's more like being respectful of other devs and handling something that Garmin knows about and has been happening for years.

Yes, Garmin knows about it and it has been happening for years, yet for some reason the onus is on devs to apply an inadequate workaround for an unrecoverable error. It's an especially reasonable ask considering the problem isn't officially documented, but the knowledge is buried in a 4 year old forum thread.

In the thread that was linked, Travis.ConnectIQ stated:

Travis.ConnectIQ said:
That said, I think that we can handle this situation a bit better. Having a limit that is shared between apps could be very frustrating for an app developer, especially when running up against that limit produces an unrecoverable error. I think it would be much cleaner for us to throw an exception if the underlying system is not able to allocate a shared resource.

This kind of thing has happened many times, where Garmin has implemented or designed something in a less than optimal way, someone who works there has said "we should probably improve this", and it doesn't happen.

That's why I always say I think the individuals who work at Garmin are passionate, but the corporate culture seems to prevent certain things from happening.