I have no luck in updating firmware on the QA402. If I load up the new Release 1.132 it wants to update, it does it . I re-connect USB but it just want to update again !! I can not not run 1.132 without update .I am running under linux (mono)
What am I doing wrong ?
Hi @Thumb, what version were you on before? If you can’t remember, then what firmware version are you seeing in the status bar? I just tried a test where I started on 1.132 and downgraded to 1.1, and then re-upgraded to 1.132 again and the firmware updated correctly at each step.
OK, so far so good on Windows. But you are on Linux.
When you update the flash, the normal USB device (VID = 0x16C0 and PID = 0x4e37) drops off and it re-appears as an NXP bootloader with a VID:PID of (0x1FC9:0x0022). So, on Linux, you probably need to add this VID:PID to the device manager rules. This similar thing had to be done before the QA402 could run.
So, probably there are two rules you need. the first is for the normal QA402 device.
sudo sh -c 'echo "SUBSYSTEM ==\"usb\", ATTRS{idVendor}==\"16c0\", ATTRS{idProduct}==\"4e37\", MODE=\"0666\"" > /etc/udev/rules.d/51-qa402.rules'
cat /etc/udev/rules.d/51-qa402.rules
sudo udevadm control --reload-rules
The above you’ve probably already done.
But to let the OS see the bootloader, you might need the following:
sudo sh -c 'echo "SUBSYSTEM ==\"usb\", ATTRS{idVendor}==\"1fc9\", ATTRS{idProduct}==\"0022\", MODE=\"0666\"" > /etc/udev/rules.d/51-qa402bootloader.rules'
cat /etc/udev/rules.d/51-qa402bootloader.rules
sudo udevadm control --reload-rules
Note, too, that the USB device when in bootloader mode is opened as a HID device, in case that makes a difference on your platform. But it’s opened specifically by VID:PID
I will give this a try later this week as I don’t know if it’s been checked before.
PS. I think the bootloader stuff should be bulletproof, and by that I mean it shouldn’t be possible to brick the device permanently. BUT, it might require you to open the case and short a header together if things get stuck. It should take 1-2 seconds to re-flash. If the app tells you it has started reflashing, you should see a progress bar and it should take a 1-2 seconds. If the progress bar is moving don’t unplug. If the app says it’s flashing but the progress bar doesn’t appear, just wait a few seconds before unplugging just in case.
I did your udev update with no luck ! But then I ran the ver. 1.132 as “root” and then it updated the flash and worked !! So I guess it is a permission problem.
So the cure is : Run as root when you are update firmware
Thanks @Matt for you nice device.
Hi Thumb, are you using a desktop computer? Did you try on Raspberry PI? There are some version on model 400 with 8GB RAM, I think that could be a good option. What do you think?
Hi @matt, I received my QA403 today and connected it to my Fedora Linux machine. I had downloaded version 1.142 version of the software, extracted the package and opened it using mono. It wanted to update the firmware and I let it proceed. But I experienced the same update loop that Thumb reported in the first post. Then I found this thread, and added the second ruleset as you instructed in the second message and I also noticed Thumb’s follow-up mesage about running the update process as root.
The update process started and it hang up. I finally disconnected the device and after that the LEDs are no longer blinking when you connect the USB cable. The QA403 was no longer visible to the software, but the other USB device shows up in log:
[26877.721590] usb 1-13: new high-speed USB device number 27 using xhci_hcd
[26877.848296] usb 1-13: New USB device found, idVendor=1fc9, idProduct=0022, bcdDevice= 3.00
[26877.848309] usb 1-13: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[26877.848315] usb 1-13: Product: USB COMPOSITE DEVICE
[26877.848319] usb 1-13: Manufacturer: NXP SEMICONDUCTOR INC.
[26877.851396] hid-generic 0003:1FC9:0022.0013: hiddev96,hidraw1: USB HID v1.00 Device [NXP SEMICONDUCTOR INC. USB COMPOSITE DEVICE] on usb-0000:00:14.0-13/input0
Now it seems that the update process failed and the software is no longer able to detect and start the update process again. Fortunately a friend of mine was nearby, and he dropped by with his Windows laptop. We installed the same software to his laptop as well, but the result was the same. The QA403 was not visible to the software.
I really hope that you have some magic trick that will enable the firmware update again.
Best regards,
-Jari
Hi @jli, there are a few possibilities, and all should be recoverable without sending the unit back.
The way the flash programming works on the QA402 and QA403 is as follows:
-
When you need to re-flash an image, the QA40x application puts the hardware into an “ISP” mode, and the processor inside the QA40x attaches to your PC with the VID:PID of 0x1FC9:0x022.
-
The QA40x app then opens the “new” device as a HID device, and an image is sent to the QA40x.
-
You then power cycle and the new image is validated as being received correct and the QA403 starts again and is ready for use.
Now, if during the update you pull out the USB plug, then upon reboot of the QA40x hardware an invalid image is detected and the QA40x firmware doesn’t start. The processor reverts to ISP mode.
And that’s where it looks like your QA403 hardware is today.
You should be able to re-flash this as follows:
- Try on a Win10 PC if possible. But if not, it’s worth a shot on Linux
- Unplug the QA403 hardware
- Start the QA40x application
- Once the app is up, click on the title bar of the app (to make sure it has focus) and type ‘QA40x’ (no quotes). You should hear a beep or similar.
- Notice there is a new menu called “DEBUG” just after the HELP menu
- Plug in your QA40x hardware, and verify a device with VID:PID 0x1FC9: 0x0022 is connected to your machine via HW manager or lsusb, etc.
- From the DEBUG menu, select
Load Default Secure Image (must in be HID mode) - Get ready to watch the status at the bottom. It will go really fast and you might not see it. But it should reflash
- Unplug the QA40x, wait 2-3 second, and re-plug. It should be connected. The cycling front-panel LEDs indicate the flash was successful.
That should get you updated to the latest version. Please report back what you see.
PS: Also, when you had the failure, had you added the second ruleset? Maybe there needs to be a better indication from the app that if you are on linux, you need to do an extra step before it tries to flash. We will fix that, but your feedback here will be very helpful. Sorry you ran into this.
PPS. Your message shows you saw the expected VID:PID, but if not, then you will need to take the lid off the QA40x. To do this, remove the two front screws and 6 side screws (3 on left, and 3 on right).The lid should lift off. Near the USB connector you will see BOOT written in the silkscreen. The two holes above the letters need to shorted with tweezers AND THEN plug in while remaining shorted. That is a fool-proof way to get into ISP mode. And from there, the DEBUG menu option above should work.
And when you put the screws back, be careful as the threads will be stripped if you go too tight.
Hi @matt , thank you for your quick response, that re-flashing procedure worked like a charm! The unit is now up and running. I did the re-flashing using Windows 10 running inside VirtualBox. I first tried to activate the DEBUG mode in Linux, but that did not work. It seems that the keystrokes are not registered and the DEBUG menu did not appear. Only visible change was toggling between ‘X LIN’ and ‘X LOG’ when ‘x’ was pressed.
PS: Also, when you had the failure, had you added the second ruleset?
Yes, the second ruleset was in place and udev rules were updated. That should be mentioned in the app or better yet, make the ‘Generate Linux USB Install Script’ option to include the second ruleset as well.
PS: The product ID for QA403 is now 4E39, not the 4E37 that the sript suggests.
I tried to update to 1.142 from 1.132 on a QA403 and it gives me a fail see picture
Any ideas ?
Aghhh… I know… I have to be “root” to update 
Did a : sudo mono QA40x.exe
And you are all good, again thanks @Matt for a wonderful product
Hi @jli, the script has been updated with the correction. Thanks!
Hi @Thumb, are you saying when you ran as root the update worked even though the rules had already been specified the bootload VID:PID (0x1FC9:0x0022)?
Hello @matt , I just plugged in my new QA403 and I am not able to update the firmware.
I am running Windows 11 with Parallels Desktop on my macOS.
When I plug in USB connection of QA403, I see a prompt to update the firmware but then get the exception message shown below.
I have tried the debug mode option “Debug → Load default secure image (must be in HID mode)”, but I get the same exception message.
I also tried forcing the device to start in IPS by shorting the boot connections on the circuit board of the QA403 and I see Parallels recognize the device as “USB COMPOSITE DEVICE #2”. But when I try running “Debug → Load default secure image (must be in HID mode)” I still get the same exception message as shown in the screenshot above.
Can you please help me figure out how to get the firmware updated? Is there a log that I can find to figure out which exceptions are thrown during the firmware update? Thank you!
Hi @RyanM, when you plug in the QA403, do you see the front-panel LEDs cycle for 1-2 seconds? If so, then there’s a valid firmware version flashed. I see your firmware looks to be version 56. I think you will need to use release 1.140 HERE until this can get sorted out OR find a PC running Windows natively (and not in a VM) and update the firmware on that.
If you don’t see the front panel LEDs cycle, let me know.
Hi @matt, thanks for your quick response.
The QA403 does cycle the front panel LEDs for 1-2 seconds, and the 1.140 version works great. I’ll use that until I get access to a windows machine for the firmware upgrade. Thank you!