Servopod Firmware overwritten

[ngkdc]

I just had a unique issue; I'm using a Servopod in an industrial environment, and just made an 18-hour, 700 mile round trip to replace a "dead" processor board. Upon returning home, I reflashed the Servopod, and it's running just fine.

This is an embedded application, the processor simply communicates with a host computer to carry out predefined commands via the SCI1 port. SCI0 is reserved for test, debug, and program upgrading.

My question ... what does it take to wipeout Isomax on a Servopod, short of overwriting Isomax address space or erasing program flash memory (neither, as far as I can determine, were done deliberately). The ONLY possible thing that may have happened was the operators may have cycled power a number of times, and since I wired the DPDT, center off switch to also ground PE4 to bypass the autostart routine, they may have cycled this pin with the power cycling.

I'm trying to understand how this occured, so I can prevent it from happening again ... this processor is very robust, and has been running in this industrial environment for over a year now ... this is the first issue I've had with a complete lockup.

I did find, in an unrelated fix, my isolated 110 VAC neutral was floating, and was not at ground potential at the source. This caused about a 70 volt differential between ground and neutral at the controller ... I MAY have had a ground loop within the cabinet. With a new processor in place and all the grounds properly connected, I'll await any future failures. However, since every input and output to the Servopod is isolated both from the AC Line and from the industrial equipment it's controlling, I'm at a loss to understand just what caused my problems. I've got the "defective" processor on my desk, running ... and will keep it running until I figure this out or it crashes again.

Suggestions? Comments? Opinions?

By the way, this processor is the heart of a very high current battery discharge machine ... I can load test 2 to 48 volt batteries by pulling up to 3000 amps out of them, for as long as they'll produce the current! Not your typical hexapod application ... but these Servopods are GREAT for imbedded processing! I just don't want to go the EPROM route to allow for easier upgrades.

Regards,

Rick

[nmitech]

Is there any PF! is being used in your program? If so, check the address where the data is storing besure is not overlap with the IsoMax Kernel. Other possibility, the user interrupt vector table maybe corrupted. Please let us know what you find out. Thanks!

[ngkdc]

Is there any PF! is being used in your program? If so, check the address where the data is storing besure is not overlap with the IsoMax Kernel. Other possibility, the user interrupt vector table maybe corrupted. Please let us know what you find out. Thanks!


No ... I'm not using program flash (though that was one area I was heading to allow user-calibration without reloading the application ... use some untouched EEPROM memory to store and read calibration constants).

Haven't heard any great cries of anguish from the customer ... so as far as I know, the system is still running from this past weekend's visit.

I'm more inclined to believe that I had a power line transient that created the event ... but being (what I hope is) a one-time event, it will be VERY hard to recreate. This machine is in a brand new facility, and the customer has had intermittent reset issues with a variety of automated processes from the start. I'm thinking that one of these days, we'll find that loose ground wire, and resolve a great deal of the issues.

I'll keep you posted ... thanks once again.


Regards,


Rick

[RMDumse]

As you say, this is at least a rare, if not one-time event. We have very few (I can't think of any) reports of Flash failure from the field beyond this one. I have seen a few looses of Flash in my own use, but again, extremely rare, and during rough handling (experimental development) so no specific pattern.

You know, it very well may be the grounding issues. That's what I first thought on reading your post, but was mulling the issue over before commenting. For all we know though, it could be some guy with a linear on his CB backed up to the wall behind the cabinet. Such rare losses are so difficult to isolate. There's just no telling. That's the problem.

Well, rest assured, since V.7, we've heard of no bugs that cause mysterious crashes. We did find some in V.6, which were a foreground-background overuse of a fixed variable (a well-known no-no in realtime programs brought to us unaware through the graces of Code Warrior library functions) but nothing of late.

So let's keep our eye on it, and see if there is (hopefully not) a repeat, or pattern.