NI-X100 Device v1.13.6 firmware problems
annuello
Posts: 294
in AMX Hardware
I'm trying to update the firmware on some NI-3100s. Master firmware has been updated to v3.21.354. Rebooted the master, and everything is fine. When I go to update the device firmware (to v1.13.6), the file seems to "transfer" unusually quick (< 1sec), then the update process never finishes. Using the telnet command "msg on all", I get the following repeated error.
Cancelling the process kills the update process, but the error message still appears. Rebooting the master does not help, since the NI-Device is now left without an address. The device does not even pick up a default address (like 32001) which I could then reassign to the standard 5001. It no longer appears to be registered with the master. Using telnet "msg on all" again, the repeating error message has now changed to the following.
I've now got two useless NI-3100s, unless there is a fix.
I've spent the whole day updating various devices & masters around the place. Some had the master updated first, then the device. Others were the opposite. It didn't seem to be an issue until now. All the successful device transfers seemed to take around 3 sec to transfer (followed by approx 60 seconds to install).
Roger McLean
Error status = -1, errno = 3997700
Cancelling the process kills the update process, but the error message still appears. Rebooting the master does not help, since the NI-Device is now left without an address. The device does not even pick up a default address (like 32001) which I could then reassign to the standard 5001. It no longer appears to be registered with the master. Using telnet "msg on all" again, the repeating error message has now changed to the following.
TaskI2CRx: timeout on readConfigs, errno = 3997700
I've now got two useless NI-3100s, unless there is a fix.
I've spent the whole day updating various devices & masters around the place. Some had the master updated first, then the device. Others were the opposite. It didn't seem to be an issue until now. All the successful device transfers seemed to take around 3 sec to transfer (followed by approx 60 seconds to install).
Roger McLean
0
Comments
Vince
I called AMX and yep, that's pretty much the case. We've got some RMAs underway.
As far as I can see, I did nothing wrong. If there is a cancel button provided for firmware transfers, the transfer should cancel gracefully, which appeared to be the case for me. Obviously there is a point of no return when doing firmware updates. My understanding is that it SHOULD do something similar to the following:
1. Transfer the firmware file
2. Do CRC check on the file - abort if corrupted
3. Unpack file into ram or flash, removing CRC
<point of no return>
4. Write over existing firmware
5. Reboot
Roger
Yesterday I updated both device and master firmware (in that order) in my test NI-3100 without a problem. There was a program running at the time of the update and it restarted without any issues. My program did not contain any Duet modules.
How about the upgrades that failed?
The problem is device firmware, I have bricked 2 NI's in the last couple of months.
Actually in one case AMX remotely downloaded some files and got it working again, but the leds were dead and it would revert to a dynamic address again if rebooted.
They were talking about the possibility of a separate program for firmware updates.
I've actually had the non-working cancel work in my favor. It was during one of those interminable long waits updating the firmware on an NI-3100.
That's one of the hallmarks of a lot of AMX programs. They're about 80% finished.
I updated six NI-3100 Master and left them for several days. I then update the Device on two and they worked fine. As I proceeded to update the next two, the failures started occuring. I stopped after that. All masters have non-Duet programs running on them, with no Duet modules.
On a slightly unrelated topic, I've also noticed is that persistent variables seem to be lost the first time the Master loses power (with a program that has persistent variables), but are retained over subsequent power losses. I imagine this would be an issue with the master firmware, not the device. Has anyone else noticed this? First noticed on v3.21.343, but it is still happening on v3.21.354.
Ah, a week of holiday as of 4pm. I can forget all of this for seven glorious days!
Roger McLean
Swinburne University
But... but... I thought we all did this for fun and couldn't help thinking about it when doing something else?
Roger McLean
Swinburne University
Honesty, I'd say even that isn't appropriate. IMNSHO, the procedure should be:
4. Write new firmware to a secondary location in flash, leaving the existing firmware intact.
5. Write a new value to a single bit pointing the boot loader to the new firmware address.
6. Reboot.
This way the entire process is atomic. It either works, or it doesn't. If there's a power failure at any point during this, you're left booting to the old firmware. You could even provide a jumper to force the master to boot to firmware location 1 or 2, maybe with a 3rd location that cannot be erased for an emergency boot.
This isn't a problem unique to AMX either. The entire electronics industry has gotten really sloppy in the way it handles firmware updates. I remember one computer I had way back in the day that had an emergency BIOS load routine that would work even if the BIOS had been completely erased. You just had to have a FAT formatted floppy in drive a: with the BIOS image named a specific way and hold some magical key sequence during boot. It was a bit of a pain to use, but when a BIOS update bricked my computer, it was nice to be able to restore to a previous version without having to send the computer back to the manufacturer.
Okay, rant over.
What a great way to start out the morning when the job was supposed to be finished *today*.
Greetings to all!
Today I have faced the same problem. I have Ni4100 with Master firmware v3.21.54 and device firmware v1.13.6, when i transfer new device firmware (v1.13.7) process has reached the end has stopped as a result to me the cancelling was necessary to press the button, after rebooting I have lost NI Device. When i open adressing and set 5001 and press ID button i find same like "NI-,Amx corp()". I'm trying transfer firmware, but i have message "Invalid ID".
http://www.amx.com/techsupport/techNote.asp?id=523 - Program Port DIP Switch - Program Run Disable (PRD) mode
There is no it does not help! And replacement of a card of memory too does not help, as device firmware is stored not on a card of memory. My program is normally carried out and now the controller works, is simple it does not see the ports.
Somebody knows, whether it is possible to correct this problem not sending the controller in AMX. In advance thanks!
You could replace the CF card. I've been taking to imaging them so I can make backups just for such emergencies.
Thanks, DHawthorne! At me is NI 3100 and I tried its card to put on NI 4100, but it has not helped.... Someone Can knows as it is possible to send compulsorily firmware, is not dependent on a mistake " Invalid firmware ID "?
Hello All!
Yesterday has collided repeatedly with a problem! It is awful! At updating firmware in new NI4100.
First has updated master firmware up to the version v. 3.30.371, was updated well and Ni was reloaded.
After that has started on updating device firmware version 1.13.7 and a problem has repeated one to one with previous!
This time I did not hasten to press the button a cancelling, waited for more than 30 minutes Ni and have not risen. But I could come on http or telnet. On all it was visible, that master worked, but device was completely dead...
After that it is possible to find Ni only having pressed on button ID. Also that the most surprising after that start to work 5,6,7 com ports!!!
Who had such problems write! AMX should know, that they have problems!
Best regards!
I have a brand new 4100 with Master firmware 3.21.354 and device firmware is 1.13.6. After reading all the issues here with the latest firmware upgrades I'm just wondering if it is worthy to go through this head ache.
Paul
I think that's pretty crappy product quality, when they tell me to do something that should be fairly trivial, I do it, and it breaks unit after unit. Customers love that stuff.
I hope our company makes the switch to any competitor soon.
EDIT: Lucked out with Unit #2... although the device was locked up and wouldn't respond to anything, I rebooted and the firmware wasn't corrupt, still on 1.12.140. I'm not updating this unit.