• Replies 50 replies
  • Subscribers 27 subscribers
  • Views 7820 views
  • Users 0 members are here
Options
Related

Major Issues with Custom Fonts after latest Device FW-Updates

forandy
over 1 year ago

Hi, the last weeks I had increasing numbers of strange reports of bugs (crashing apps) on most of my apps. It became more and more clear, that mostly it happens after latest FW updates on devices, but I was not able to locate based on log files. On simulator I have absolutely no issue.

This week I updated also my devices and had the same issue. Even on old devices like FR645M (yes, there was also a FW update !!!) after this update I've the same issue.

After many hours it seems to be, that some of the customer Fonts I set up with BMFont64 lead to the crash:

Error: System Error
Details: 'Failed invoking <symbol>'

At code customFont = Ui.loadResource(Rez.Fonts.icons);

I did not change the code, and not all of the fonts are affected. I cannot find any rule if BMFont64 setting is leading to the bug. Already tried to play with BMFont64 settings with no success.

Again it only happens based on devices with the latest FW-Update. And on simulator everything is ok.

Has anyone the same issue and maybe any idea ?

  • over 1 year ago in reply to trudelta

    For me as well! This is the correct way to fix it at the moment, although technically it shouldn't be done. This should still be fixed by Garmin. But it works as workaround.

  • over 1 year ago in reply to _psx_
    _psx_ said:
    Why there is no error on the sim?

    The simulator is compiled from a different version of the virtual machine source code than the device(s). The fr645m and edge130plus are using source code that has this bug. The ConnectIQ simulator and other devices are using sources that do not have the bug.

    In order for the simulator to behave exactly like a device, we'd have to either compile the virtual machine code for each device used and dynamically load that, or we'd have to get every device to use the same version of the source code. Neither of these can easily be done.

    _psx_ said:
    That's what the FNT file compiler is for, to check its correctness of it instead of generating some garbage that generates errors on the end device.

    Yes. We did not realize that this issue was present in these device firmwares. The appropriate place for a fix of this type is at the compiler level... this would not break existing apps and would enforce correctness when the app is built the next time.

    _psx_ said:
    I wrote about problems with fnt files a long time ago, but no one reacted.

    I have no idea what issues you are referencing. I do know that this exact issue came up previously and was fixed then. Unfortunately the old issue was duplicated for these devices, and the fix was not.

  • over 1 year ago in reply to Travis.ConnectIQ

    Is does mean soon bugged devices will get new firmware?

  • over 1 year ago in reply to _psx_

    With a device like the 645m, which is kind of old right now, the product people may only release new FW a few times a year.  The best thing to do is change the impacted fonts - I only had one - a hand crafted icon font - but it was used in a number of apps)  and upload a new version of the app to the store.  It was a minor change to the fnt file

  • over 1 year ago

    Will it be fixed and when? Garmin, what is going on?

  • over 1 year ago in reply to a1234.garmin

    The 645m is a pretty old device at this point, and the last FW for it was 6 months back (when this problem first started).  This fix would be in the FW, but who knows if that will ever happen as the device looks to be end-of-life.  A small edit to one the fnt file was all it took for me.

  • over 1 year ago in reply to jim_m_58

    Jim may be right that we'll never see a new firmware version for this device.

    The ideal fix might be in the firmware, but the dev team could also fix it by doing the fnt edit "behind the scenes" while they are assembling the prg file. This way new builds would have the workaround automatically implemented, without requiring anything from the end-developer.

  • over 1 year ago in reply to jim_m_58

    All of this means only one thing, they don't control the code. They had the guts and courage to go through the whole process of building the firmware, compile it, publish it, get negative feedback in tech support from these glitches, listen to the anger of the developers. Instead of sitting down at the table and admitting, yes, we screwed up, and roll back the changes, remove this glitchy firmware in the end. And no one guarantees that the same thing can't happen in the next generation of devices. Anything can happen, and the same old bugs will pop up that everyone forgot about long ago. I have no illusions, I had to correct fonts, okay, I have 5 of them and not so many watchfaces, but what should other developers do? I guess they shut this buggy device out of support. Monkey labor, turning off the checkbox, yeah.

    Demotivating. As soon as a user complaint arrived with a couple of stars (I confess. the first desire was to remove support for this device, but held back). I remembered how garmin repeatedly reproduced glitches in the next generations of devices. I decided to write here. Maybe they will hear.

  • over 1 year ago in reply to jim_m_58

    What did you do to fix this?