Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Reverting Firmware Problem
#1
Hello,
I started with a fully functional machine, with the desire to update the firmware from 1.6.1.1 to 2.02.14 (460EX). I first created a recovery disk 'Power PMAC Complete' using the IDE. I next installed the new firmware after normal $$$***, save, etc. We are using MuxIO through ACC5E, and with the new firmware the MuxIO would not function. In the essence of time, decided to revert back to the 1.6.1.1 firmware using the recovery disk I had created, as well as trying to load the firmware and project manually. In either case, the MuxIO will no longer function. The system is configured with MuxIO.PortA[].Data as inputs, and MuxIO.PortB[].Data as outputs. I see no input data from hardware. I can write to output data, but it's not getting to the hardware. Two questions:
A. Apparently something is not getting restored, so how can I get back to original state?
B. Has anyone used MuxIO through ACC5E, with the current 2.0.2.14 Firmware, and if so is there something that I need change to make compatible.

Thank you
Reply
#2
Toggle the MuxIO.Enable - this should restart the Power PMAC executable. What are your MuxIO settings?
Reply
#3
(06-26-2015, 10:50 AM)steve.milici Wrote: Toggle the MuxIO.Enable - this should restart the Power PMAC executable. What are your MuxIO settings?

Thanks for the reply. I tried toggling the MuxIO.Enable, No difference.
MuxIO Settings:

MuxIO.ClockPeriod = 8; //8usec (125Khz) clock rate
MuxIO.InBit = 8;
MuxIO.OutBit = 16;
MuxIO.pIn = Gate2[0].MuxData.a; //Input register pointer
MuxIO.pOut = Gate2[0].MuxData.a; //Output register pointer
MuxIO.UpdatePeriod = 5; //5 msec scan rate
MuxIO.PortA[2].Dir = 0; //1st PortA addr are inputs
MuxIO.PortA[4].Dir = 0; //2nd PortA addr are inputs
MuxIO.PortB[2].Dir = 1; //1st PortB addr are outputs
MuxIO.PortB[4].Dir = 1; //2nd PortB addr are outputs
MuxIO.PortA[2].Enable = 1; //Enable 1st PortA addr
MuxIO.PortA[4].Enable = 1; //Enable 2nd PortA addr
MuxIO.PortB[2].Enable = 1; //Enable 1st PortB addr
MuxIO.PortB[4].Enable = 1; //Enable 2nd PortB addr
MuxIO.Enable = 1; //Enable the firmware Mux IO
Reply
#4
Also check your Gate2 hardware settings; typical for ACC-34x hardware:
Gate2[0].PartData[1]=3
Gate2[0].MuxDir=$FF00;
Gate2[0].MuxMode = $FFFF
Gate2[0].MuxPol = 0
Reply
#5
(06-26-2015, 12:57 PM)steve.milici Wrote: Also check your Gate2 hardware settings; typical for ACC-34x hardware:
Gate2[0].PartData[1]=3
Gate2[0].MuxDir=$FF00;
Gate2[0].MuxMode = $FFFF
Gate2[0].MuxPol = 0

The only setting I see different is Gate2[0].PartData[1]=$FFF1, but this is the same setting of alternate machines that are functioning fine. It still seems like something is corrupt on the CPU card, as I can take another CPU card from another machine with the same firmware, do a $$$*** reset, load the project, and all works fine. Our muxIO setup is included in the project.
Reply
#6
Try implementing this post to fix the file system and then reload the firmware:
http://forums.deltatau.com/showthread.ph...38#pid4238
Reply
#7
(06-26-2015, 08:06 AM)wehg Wrote: Hello,
I started with a fully functional machine, with the desire to update the firmware from 1.6.1.1 to 2.02.14 (460EX). I first created a recovery disk 'Power PMAC Complete' using the IDE. I next installed the new firmware after normal $$$***, save, etc. We are using MuxIO through ACC5E, and with the new firmware the MuxIO would not function. In the essence of time, decided to revert back to the 1.6.1.1 firmware using the recovery disk I had created, as well as trying to load the firmware and project manually. In either case, the MuxIO will no longer function. The system is configured with MuxIO.PortA[].Data as inputs, and MuxIO.PortB[].Data as outputs. I see no input data from hardware. I can write to output data, but it's not getting to the hardware. Two questions:
A. Apparently something is not getting restored, so how can I get back to original state?
B. Has anyone used MuxIO through ACC5E, with the current 2.0.2.14 Firmware, and if so is there something that I need change to make compatible.

Thank you

From post ACC5E unavailable.

(04-29-2015, 09:39 AM)steve.milici Wrote: Note that we will be releasing a firmware version that corrects a clocking issue with the MUXIO that allows for full transmission rates very soon:
MuxIO.UpdatePeriod=1;
MuxIO.ClockPeriod=0;

We have been running with MuxIO.UpdatePeriod = 5 and MuxIO.ClockPeriod = 8 from version 1.5 through version 2.0.0.1 with Acc34 class devices. It is only the latest version (2.0.2.14) that does not work. I assume 2.0.2.14 was the new firmware you were referencing Prior when you sere suggesting a ClockPeriod=400 and UpdatePeriod=48?
Reply
#8
(06-26-2015, 02:02 PM)steve.milici Wrote: Try implementing this post to fix the file system and then reload the firmware:
http://forums.deltatau.com/showthread.ph...38#pid4238

I wasn't able to successfully copy the uImage file from the PC to PPMAC memory using this post. I put the tfpt server and associated files on a shared folder on the PC with read/write permissions. I configured the serial communications for 115200, 8bit, Parity None, Stop Bits 1, Flow Control none. I've verified the batch file paths are correct, and triple checked the IP addresses, and continually get a Timeout error just showing T's and no ####...

I was able to download the uImage from this post using the IDE Kernel Update tab, then followed with 1.6.1.1 firmware download.

I also have tried extracting the 1.6.1.1 uImage from the 1.6.1.1.deb package, and downloaded it through the IDE as well, followed by again downloading the 1.6.1.1 firmware.

Neither sequence has brought the Muxio back alive, with again trying toggling the Muxio.Enable. Am I safe to assume that loading the kernel through the IDE has the same affect as loading it via the tftp server? (The available memory check as referred to by an alternate post, indicated PPMAC had adequate memory.) If so, I'm not sure how best to proceed?
Reply
#9
I don't know enough about the tftp server to say but you might try using it in the specified directory as in the post just to eliminate this as a factor. If the firmware downloads without issue and the project has no download errors and the "save" command is successful then I don't think there is any issue with the file system.

I was able to upgrade an older 460EX CPU to the 2.0.2.14 firmware and get the MuxIO to work with the following hardware ACC-24E3[2] (does not affect the following configuration code) card and ACC-5E[0] card connected to an ACC-34A (from $$$***):
Gate2[0].PartData[1]=3
Gate2[0].MuxDir=$FF00;
Gate2[0].MuxMode = $FFFF
Gate2[0].MuxPol = 0
MuxIo.Enable=0
MuxIO.pOut=Gate2[0].MuxData.a
MuxIO.pIn=Gate2[0].MuxData.a
MuxIO.OutBit=16
MuxIO.InBit=8
MuxIO.UpdatePeriod=1;
MuxIO.ClockPeriod=0;
MuxIO.PortA[0].Enable=1;
MuxIO.PortA[0].Dir=0;
MuxIO.PortA[0].AutoParityCheck=0;
MuxIO.PortB[0].Enable=1;
MuxIO.PortB[0].Dir=1;
MuxIO.PortB[0].AutoParityCheck=0;
MuxIO.PortB[0].Data=$0
MuxIO.Enable=1;
Reply
#10
If the power on technique for setting the direction control (Cid[x].PartData[1] or Gate2[x].PartData[1]) of the Gate2 JTHW port is in pp_startup.txt, slight variations in power on timing could be the cause. Try setting this manually to verify if this is the case.
Reply
#11
(06-30-2015, 10:01 AM)steve.milici Wrote: If the power on technique for setting the direction control (Cid[x].PartData[1] or Gate2[x].PartData[1]) of the Gate2 JTHW port is in pp_startup.txt, slight variations in power on timing could be the cause. Try setting this manually to verify if this is the case.

The settings are in pp_startup, so I tried disabling, issuing commands manually, and re-enabling. No difference.

This is what I've learned today:
Jeff had mentioned earlier today that he had previously had Muxio functioning with 2.0.0.1 firmware. I updated from 1.6.1.1 to 2.0.0.1 and the Muxio immediately started functioning normally. Next I updated from 2.0.0.1 to 2.0.2.14, at it immediately broke. What I'm currently seeing is that inputs are changing, but they are not as expected. As an example, our feedrate override switch is looking at 4 bits of a 32 bit word, in most cases (not all) of changing the switch position, the value changes, but none of the switch positions reflect the correct value. Outputs are now changing state, but outputs that should be unrelated to specific inputs, are turning on/off when the unrelated input changes state. It acts like something has either changed in the addressing or data transfer. I've tried slowing the clock period and Update period way down from your settings, and it seems to have no affect.

In case it's of help, in summary the sequence I've been through to break and un-break things:

updated from 1.6.1.1 to 2.0.2.14 broke Muxio.
reverting back to 1.6.1.1 did not restore to functional.
updated from 1.6.1.1 to 2.0.0.1 fixed the problem.
updated from 2.0.0.1 to 2.0.2.14 broke it again.
Reply
#12
I just want to be clear....did you try the "ON" switch?

;-)

Good luck sounds like a tough one!
Reply
#13
This has since been corrected in a firmware update. There were some subtle differences in the “edge” timing of the DAT and SEL lines in the control panel you have compared to our ACC-34x hardware.
Reply
#14
(11-16-2015, 10:21 AM)steve.milici Wrote: This has since been corrected in a firmware update. There were some subtle differences in the “edge” timing of the DAT and SEL lines in the control panel you have compared to our ACC-34x hardware.

Which version of Firmware? 2.0.0.1 works ok, the current release 2.0.2.14 does not work. Is there a newer version?
Reply
#15
This will be in the December release.
Reply
#16
(06-30-2015, 12:59 PM)wehg Wrote:
(06-30-2015, 10:01 AM)steve.milici Wrote: If the power on technique for setting the direction control (Cid[x].PartData[1] or Gate2[x].PartData[1]) of the Gate2 JTHW port is in pp_startup.txt, slight variations in power on timing could be the cause. Try setting this manually to verify if this is the case.

The settings are in pp_startup, so I tried disabling, issuing commands manually, and re-enabling. No difference.

This is what I've learned today:
Jeff had mentioned earlier today that he had previously had Muxio functioning with 2.0.0.1 firmware. I updated from 1.6.1.1 to 2.0.0.1 and the Muxio immediately started functioning normally. Next I updated from 2.0.0.1 to 2.0.2.14, at it immediately broke. What I'm currently seeing is that inputs are changing, but they are not as expected. As an example, our feedrate override switch is looking at 4 bits of a 32 bit word, in most cases (not all) of changing the switch position, the value changes, but none of the switch positions reflect the correct value. Outputs are now changing state, but outputs that should be unrelated to specific inputs, are turning on/off when the unrelated input changes state. It acts like something has either changed in the addressing or data transfer. I've tried slowing the clock period and Update period way down from your settings, and it seems to have no affect.

In case it's of help, in summary the sequence I've been through to break and un-break things:

updated from 1.6.1.1 to 2.0.2.14 broke Muxio.
reverting back to 1.6.1.1 did not restore to functional.
updated from 1.6.1.1 to 2.0.0.1 fixed the problem.
updated from 2.0.0.1 to 2.0.2.14 broke it again.

Going through the exact same issue as of July 2017 without any accessories, just the PMAC 465 board and now going from 2.0.2.14 to 2.1.0.39
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)