I am attempting to upgrade the firmware on my Zubax GNSS 2.2 running FW 4.0 to the latest version.
Having read through a variety of documentation (which, by the way, I feel is a bit fragmented), I progressed all the way up to the point where I attempt to put the bootloader into “download” mode. It simply gives the -20002 error, which signifies exhaustion of attempts. However, this error is returned after merely a couple seconds, whereas the YMODEM is supposed to wait one minute. I suspect there may be something wrong with my command sequence or setup.
Potentially important is my environment - I am running sz and minicom from the bistromathic VirtualBox image provided by Zubax - when changing modes (i.e. entering the bootloader from CLI) the device disconnects from the VM and I must reattach it through VirtualBox.
I have attached images of the command sequence and error below.
I had not been closing minicom originally, however I just attempted running bootloader (reconnect) then download (quickly closed minicom terminal), followed by the sz command, but still received the same ZNAK output from sz as before.
I will try the bin upload directly from windows (assuming I can find a YMODEM application) and update on the results.
I attempted again with ExtraPutty for Windows, but I see the same behavior on the bootloader side (I don’t even get a chance to close the terminal before it returns error -20002). That said, its a little odd with this program that the terminal and YMODEM are in the same session . . .
$ chmod +x flash_via_serial_bootloader.sh
$ ./flash_via_serial_bootloader.sh com.zubax.gnss-2.2-4.1.62c8d4a.application.bin /dev/ttyACM0
Configuring the serial port...
Using serial port: /dev/ttyACM0
Configuring the device...
Using serial port: /dev/ttyACM0
Starting YMODEM sender...
Sending: com.zubax.gnss-2.2-4.1.62c8d4a.application.bin
Bytes Sent: 181248 BPS:20614
Transfer complete
Oddly enough, once I fixed that, I keep getting:
“bash: /dev/ttyACM0: Permission denied”
I also found that each time I do anything to the GPS CLI, it adds a duplicate ttyACM0 device . . .
What you’re seeing in the screenshot is not new devices, it’s just the output of the Linux kernel log. Every item that you’re interpreting as a duplicate device is just a notification from the kernel that a new device has been detected (which is natural since you’re disconnecting and then reconnecting the device back). At any rate, dmesg is not the right place to look for that information, it’s needed for completely different purposes. Instead, you should be looking into /dev/serial/by-id, or just /dev/ttyACM*.
Made a couple mistakes along the way, but ultimately that script and the udev settings did the trick.
Uploaded without further issues.
I wonder if the udev settings may have been the root of the issue. I assumed that because MiniCOM worked with the shell, that the device settings were fine. TIL.