Zubax GNSS 2.2 Firmware Upgrade Difficulty

Support GNSS
1

Hello All,

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.

Screenshot_20180427_001451
Screenshot_20180427_0014511600×795 201 KB

2

Could you please confirm that you close the terminal and all other applications that might be using the serial port before running sz?

3

Thank you for your response -

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.

4

I just looked at your screenshot again and noticed that you’re using incorrect path separators: you should use / instead of \, e.g. /dev/ttyACM0.

1 Like
5

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 . . .

image

6

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 . . .

image
image668×533 52.8 KB

7

I couldn’t reproduce your problems locally. Please try using the following script on Linux (e.g. on your VM): https://raw.githubusercontent.com/Zubax/zubax_chibios/e432b575b64a58786b751b270bce424c6b7c2459/tools/flash_via_serial_bootloader.sh. Configure your VM to automatically attach the device to the VM for extra convenience.

Example:

$ 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”

This is because udev is not properly configured. Please follow this guide to get this fixed: Using USB devices with GNU/Linux - Knowledge Base - Zubax Knowledge Base

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*.

8

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.

Thank you.