Home AMXForums Archive Threads AMX Hardware

NI-X100 Device v1.13.6 firmware problems

annuelloannuello Junior MemberPosts: 294
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.
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

Comments

  • vincenvincen Junior Member Posts: 526
    If the NI-Device doesn't appear at all either in dynamic or fixed ICSNet adress, you'll probably need to return NI to AMX to get it flashed as now the NI-device is unavalaible for update from NSX :(

    Vince
  • annuelloannuello Junior Member Posts: 294
    Gday 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
  • DavidRDavidR Junior Member Posts: 62
    this exact same thing happenned to me and now I scared to do any other device firmware updates. even though there is new device firmware I won't use it until this is fixed.
  • No problem here

    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?
  • DavidRDavidR Junior Member Posts: 62
    Code was running and I am not using any Duet modules. Master firmware upgrades are fine and they recover if incomplete.

    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.
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I recently killed an MVP-8400 the same way. Its existing firmware was from before the 7400-8400 split, and I accidentally sent it the 7400 firmware. Being one of the older panels, NS allowed this. I realized my mistake halfway through the transfer and canceled it. The panel went off line, and never came back. The display was scrambled, and the setup pages non-functional. It had to go back to AMX to be fixed. I complained quite loudly with the tech support person (poor guy, not like it was his fault) about cancel buttons that didn't really cancel. If I had let the stupid thing finish, I would have been OK to load the correct firmware afterwards, but the cancel wiped it out instead.
  • ericmedleyericmedley Senior Member - 4000+ posts Posts: 4,177
    DHawthorne wrote:
    I recently killed an MVP-8400 the same way. Its existing firmware was from before the 7400-8400 split, and I accidentally sent it the 7400 firmware. Being one of the older panels, NS allowed this. I realized my mistake halfway through the transfer and canceled it. The panel went off line, and never came back. The display was scrambled, and the setup pages non-functional. It had to go back to AMX to be fixed. I complained quite loudly with the tech support person (poor guy, not like it was his fault) about cancel buttons that didn't really cancel. If I had let the stupid thing finish, I would have been OK to load the correct firmware afterwards, but the cancel wiped it out instead.

    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. :)
  • annuelloannuello Junior Member Posts: 294
    B_Clements wrote:
    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?

    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
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    annuello wrote:
    Ah, a week of holiday as of 4pm. I can forget all of this for seven glorious days!

    But... but... I thought we all did this for fun and couldn't help thinking about it when doing something else?
  • annuelloannuello Junior Member Posts: 294
    Just to compete this thread, my two RMAs came back. U22 was replaced in both masters. I hope AMX can find what caused this issue, and get it sorted out so I can continue to standardise the firmware across my masters.

    Roger McLean
    Swinburne University
  • mstocummstocum Junior Member Posts: 119
    annuello wrote:
    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

    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.
  • jjamesjjames AMX Sustaining Engineer Posts: 2,901
    Just ran into this problem - but when *downgrading* the device firmware to 1.13.2 on an NI-4100. I'm currently waiting to hear back from AMX as to what to do. Our installer here said go for broke and just reboot the thing. I dunno though.

    What a great way to start out the morning when the job was supposed to be finished *today*.
  • KimKim Junior Member Posts: 51
    NI4100 The device has been lost

    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".
  • jjamesjjames AMX Sustaining Engineer Posts: 2,901
    Try turning off the program via the dipswitch on the back of the NI, and reboot. See if you can get the device info that way. If so, try re-downloading the firmware. This is what I did last time and it worked. Good luck!

    http://www.amx.com/techsupport/techNote.asp?id=523 - Program Port DIP Switch - Program Run Disable (PRD) mode
  • KimKim Junior Member Posts: 51
    Thank jjames! But.
    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.
  • KimKim Junior Member Posts: 51
    Help!
    Kim wrote:
    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".

    Somebody knows, whether it is possible to correct this problem not sending the controller in AMX. In advance thanks!
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    Kim wrote:
    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.
  • KimKim Junior Member Posts: 51
    Need help!
    DHawthorne wrote:
    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 "?
  • KimKim Junior Member Posts: 51
    Device Firmware update, Big problem!
    Kim wrote:
    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".

    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!
  • flcusatflcusat Junior Member Posts: 309
    Kim wrote:
    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.
  • a_riot42a_riot42 AMX Wizard Posts: 1,619
    I seem to recall something like this happening to me and after a firmware upgrade my 5001 device was no longer in the online tree. However, I did now have a virtual device that hadn't been there before. I went in and manually change that new virtual to 5001 and it worked fine after that.
    Paul
  • viningvining X Member Posts: 4,368
    From another thread DHawthorne wrote:
    Check your device addresses. I've had an NXI chassis lose it's address; it had been set to 5003 (third one on the master), and had inexplicably changed to 32001. That, of course, made all the ports on it inaccessible. It was easy enough to fix, and never repeated on that system (in over a year now). I never did figure out what caused it, but I suspect power flucuations of some sort.
    I believe it's a default that some devices that for what ever reason loose their ID because of a conflict or what ever get set to 32001 or the next unused virtual device ID number. I know several devices will do this although I don't recall why. So if something goes missing look in the 32000 for something new and then change it back.
  • Joe HebertJoe Hebert Junior Member Posts: 2,159
    vining wrote:
    I believe it's a default that some devices that for what ever reason loose their ID because of a conflict or what ever get set to 32001 or the next unused virtual device ID number. I know several devices will do this although I don't recall why. So if something goes missing look in the 32000 for something new and then change it back.
    The 33000 range is the virtual device range. 32000 is the dynamic address range (the DHCP for Netlinx). It's how Netlinx Studio and TPD4 can show up in the online tree. If a device doesn't have an address or loses its address it will be issued a dynamic address when it comes online. If you do get a dynamic address you obviously must change it or your code will easily break since the dynamic address can change the next time it comes online as it's first come first serve when handing out device IDs.
  • truetrue Junior Member Posts: 307
    I am having this issue now as well. Flashed an NI-3100 yesterday per AMX recommendation, had this issue, called AMX and they quickly said to send it in - no troubleshooting. I just went on flashing another one and it is dead now, too.

    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.
Sign In or Register to comment.