Bugfixing a frozen LEGO SPIKE Prime (.llsp) file

Recently a case of freezing / hanging LEGO SPIKE Prime file was shown to me by a coach heading to a competition with her kids the very next day (2.0.5, Win10).

The problem

The file could not be opened and the LEGO Spike App started with and error message. To dig deeper we do need to understand the architecture of the LEGO SPIKE App.

LEGO Software Architects decided a few years back to discontinue the problematic supporting of NI LabView due to most probably performance, stability and scalability issues. Creating a full blown framework in 2018ish would have been quite an expensive decision therefore they have probably looked for an easy to use blocky low-code/no-code alternative.

As nowadays MIT Scratch is essentially a kind of standard and the community already created a solution to replace the quite disturbing WeDo 2.0 application -that is another story- with a WeDo Scratch support, this architecture must have seen tempting here as well.

This stack creates a side-loaded application that handles the hardware connection (WeDo Link), while Scratch itself gets an extension (WeDo Extension) that provides the additional block types.

The Architecture

The LEGO Spike application is using quite a modern architecture of creating a React application that runs as a web application in any browser running the MIT Scratch 3 framework with a SPIKE specific extension on top.
A native side component handles device management such as USB and Bluetooth connectivity.

In fact EV3 and Robot Inventor apps use the very same structure. With an exception that for EV3 a genial pattern-based replacement is created instead of the versatile-but-complex-NI-compilation process.

Packaged web app using a chromium frame running on your machine is quite a popular choice: Microsoft Teams, Slack, Discord, just to name a few. Cross platform compatible, yet sluggish with performance and lacking native features like file or easy shortcut-keyboard access.

Fun fact: while the Spike app is running, just type this into your Chrome (danger! for entertainment purposes only).

http://localhost:1995/?appId=spike&debugUrl=http%3A%2F%2Flocalhost%3A1995%2Fdebug&defaultLanguage=en-US&fullVersion=2.0.6-latest-flipper.106386&sentryEnabled=1&webUrl=http%3A%2F%2Flocalhost%3A1995&wsUrl=ws%3A%2F%2Flocalhost%3A1995

The problem – revisited

Without further ado let us see what the Spike App actually does after opening a Scratch canvas with Spike specific blocks on the palette?

In a separate blog post I have dug deeper into settings and even a hidden debug menu for Spike to show that the log files for the app can be found c:\Users\<username>\AppData\Local\Packages\LEGOEducation.SPIKELEGOEducation_by3p0hsm2jzfy\LocalCache\Roaming\SPIKE\log.txt

Here we can see several log messages, and some usual errors. What is “easy” to see is that here these error lines are duplicated.

#$@!% I hate “usual” errors

Have you noticed the product decision was to remove the problematic “Save file” menu so kids don’t forget to save their work? This was a common problem when the EV3Lab used to crash in its years of instability 2014-2018ish.

At every change the program auto-saves the file that has the following double-zipped format.

Program.llsp is a zip file, containing generic project descriptor, a complete vector screenshot of the program for preview and a standard Scratch 3 file.

The scratch file consists the content project file and any media files (sound files and additional sprites – not applicable in Spike environment).

The key file carrying all data is project.json using JavaScript Object Notation containing a quite flat structure of node-stacks as seen in the editor and some misc data such as variables.

Checking the file closely in my json editor I could see that the content structure was duplicated.

The Solution

From this point it was fairly easy to fix the problem. Deleting the two duplicated nodes and re-zipping the file to scratch.sb3, then re-zipping the upper structure to program.llsp yielded to a pretty stable and working file again.

Happy end as also the kids were able to compete the next day and also win their category. Would have been a shame to let infrastructure ruin the diligent work of young kids.

I will be sharing this bug with the LEGO engineering team as well to have this issue fixed.
If you happen to have contacts, please let them hear our word that we’d like a much more stable and enabling environment as we ❤️ LEGO and kids.

Update: David Lechner and Ravi Sambhara have found this bug and solution already in February, 2022 with EV3 Classroom 1.5.2. Let’s shout out to get this fixed soon!

Update2: I have created a small Lego App Tool kit to fix the problem, until LEGO service team does.

Leave a comment

Design a site like this with WordPress.com
Get started