SO3 with GRBL 0.9 --> 1.1 Issues on OSX and Resolution

Hey all - I’m new to the forums even if I’ve had my SO3 for a while. I wanted to post this just in case anyone ever faces a similar issue.

Basically, Carbide GRBL Updater (as described here) could not update my SO3 from GRBL 0.9 to 1.1. I wanted to upgrade so that I could use CM4, but mostly to use the touch probe I had gotten a few months ago. Job and Family kinda took most of my time so I just hadn’t gotten around to it.

Using my 2013 Macbook Air, I tried to go through the update process, but there was one problem… when prompted to hold Z-limit and press ‘Yes’, I would get a progress bar that simply did not change. I think the longest I waited was 5 minutes. Restarting the computer, power cycling the SO3… nothing changed. I could still easily connect to CM3. Homing operations worked just fine so I knew the switch was fine and hooked up correctly.

After contacting support, Will suggested that maybe my Atmega chip didn’t have a bootloader. It’s not strictly necessary unless you want to update anything so he mentioned trying the Adruino ISP approach to re-burn one. Conveniently I had an Uno lying around so I gave it a shot. A full day of researching, trying, and failing later, and I had to wave the white flag. Turns out, OSX (or macOS these days I guess) 10.15 is the one where Apple killed support for 32-bit apps. This is only a problem because Arduino IDE 1.8.10 (you need the IDE to do the burn or you need to do it with a command line AVR toolchain) seems to have broken support for burning bootloaders via ArduinoAsISP. I couldn’t find anything online saying it had worked since before 1.8.6. Unfortunately (here’s that OSX problem), 1.8.5 is not 64-bit.

So… I tried ignoring the IDE approach and just going with command line and that was a significantly more convoluted flow. I got all the software working on the laptop, but I couldn’t get it to initialize with the SO3’s board. Either I would get STK param errors (“expected 0x14 received 0x12” or whichever one means “unknown error”) and it would fail or I’d get a sync timeout failure. Eventually, I gave up.

Enter Brandon who suggested using Xloader or HexUploader for mac as mentioned in this. That thread was for going back from 1.1. to 0.9, but the process is identical. Hold Z-limit (it doesn’t prompt like with the Carbide Updater), click upload on a hex file, wait. Strangely enough, it worked right away. The log printed out everything I expected to see when I tried the command line and Arduino IDE methods, but none of the errors. I booted up CM4 and it connected to the SO3 just fine. I haven’t run a test cut or tried the probe yet, but I’m still calling it a win.

TL;DR: If CarbideGRBLUpdater doesn’t respond as described and you can’t upload a hex file, try HexUploader before tearing any hair out. Thanks to Brandon and Will for their support.


Thank you for taking the time to write these details, I’m sure sooner or later it will save someone’s day !