I hunted for prebuild DOS/VS packs I could use on the P390 under VM. The first system I found, consisting of two packs, has the exact same error when I IPL - takes the supervisor name then goes into a loop.
My VM system is set up for a five pack DOS/VS system, which matches lots of posts and comments online but I had to hunt quite a while to find an active site where I can download these five almost-mythical packs. I found them (in compressed CKD format), converted them to the AWSCKD format and burned them onto CDs for transfer to the P390 system.
It is a slow process to transfer them over, but I put in the time tonight in order to attempt to bring up the five pack DOS/VS system and begin debugging my from-scratch sysgen process. I followed all the directions exactly, but each time that I 'dial in' to the DOS/VS machine to boot it up, VM restarts because something bad happened.
This is quite frustrating - doing a direct IPL of the pack gets the same tight loop in the supervisor as I experienced with the other pre-built system and that I see with my restored pack from the distribution tape. At this point, I suspect I will need to move over to a PC and use Hercules to fire up the premade DOS system, look up the supervisor code and then debug on the P390.
PERTEC D3422 DRIVE RESTORATION
I didn't like the way that the parts tester reported on one of the two darlington transistor pairs - these are a pair of transistors, a couple of resistors and a diode all stuffed in a single TO-3 transistor can. Thus the three terminals, E, B and C, are composite devices and not single junctions or simple devices that the automated tester can understand.
The cost of the parts is low so I picked up replacements, plus a few more of the LM741 op amps that I keep frying. I also worked out a testing regime that should pinpoint the problem with the positioner power without having to burn up op amps or blow fuses. I removed the two E terminals again, so that the rest of the circuitry behaves well, and then tested the positioner circuitry.
I looked at what voltage is present on the driving op amp, its +, - and output levels, to divide the investigation into the logic that sets the voltage versus the circuitry that amplifies the voltage and powers the voice coil to move the arm.
Since I was suspicious about one of the darlington pairs, that is the place I expected to see a problem. Specifically, I expected the upper pair that passes the +20V to be essentially a short circuit, delivering +20V (minus voltage drops in the circuit), while the bottom transistor pair should be near ground.
Based on the wacky results with the component checker, and the perfect results of the replacement darlington pairs, I replaced the parts on the heat sink. They were clearly bad, one short circuited and the other with a damaged junction or junctions inside. I don't want to think of the possibility that the voice coil itself was damaged, as that is a non-replaceable part which renders the entire drive into junk or a spare parts repository.
First, before I put power to these transistors and possibly fried them again, I did the check on the op amp with the transistors out of circuit, since the op amp tells the power section what voltages to deliver. If the op amp is swung towards the positive rail (+10V), the power section is legitimately driving towards its most positive level.
If the op amp was not putting out nearly 10V, I have a problem in the power section. If the op amp was driving high, I would have to investigate the cause upstream of the amp, starting with the values on the + and - inputs.
The testing quickly showed that the op amp was driving out about -3.6V but with its inputs of approx 0.002 and 0.003 so not sure this is as it should be. With the new transistors out of the circuit, this might be how it would act. I connected the darlington pairs back into the circuit and fired everything up.
Everything held - good solid regulated power at +10V, -10V, +5V and -5V. The positioner amp output was running at almost -20V, which is the emergency unload level that protects the heads by pulling the arms out of the pack when things are not safe. The emergency unload relay doesn't activate until several 'safe state' signals arrive at the transistor that energizes the coil.
Those signals will be produced on other boards, but those boards are not connected to this one currently since I am still debugging everything. I am feeling more optimistic now that the power seems to hold without smoke, fuse pops or other problems. Time to re-install my SCR crowbar protection components then move forward on my restoration.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Richard Stofer generously offered to meet me, bringing his setup, so that we could get to the bottom of the problem I am having storing my fpga code in the ztex board in a way that will autoconfigure the fpga at power-on.
We met at noon in a Starbucks about equidistant from our homes, since we are almost two hours apart. We both have the same boards and our own toolkits on laptop or tablet machines, which made a set of substitutions the right tests to perform first.
My toolchain (Xilinx etc) was able to load the flash memory on Richard's board and it booted up fine when power was cycled. My board continued to fail. Richard used his toolchain to write to my board's flash, which reported success as it always does but in fact my board didn't boot.
We ran the flashbench demo which writes to and then reads from flash, verifying that my flash is functional. We loaded the fpga just fine dynamically, but nothing would make my board load the fpga at power up. We have to conclude that my board is somehow broken.
I chose to do some checking to see if there is any way that my circuitry in the SAC box might be able to damage an fpga or USB chip pin that is needed for power-on autoconfigure but not used to separately load the fpga or access the flash. I had to study the schematics and other documents to learn what IO pins are used for power-on configuration, then see whether (and how) I might be using them.
Richard gave me his board to speed up my resumption of SAC Box debugging, since it will take some weeks roundtrip to get a replacement board from Ztex in Germany. Once the replacement comes in, I will return it to Richard.
My toolchain (Xilinx etc) was able to load the flash memory on Richard's board and it booted up fine when power was cycled. My board continued to fail. Richard used his toolchain to write to my board's flash, which reported success as it always does but in fact my board didn't boot.
We ran the flashbench demo which writes to and then reads from flash, verifying that my flash is functional. We loaded the fpga just fine dynamically, but nothing would make my board load the fpga at power up. We have to conclude that my board is somehow broken.
I chose to do some checking to see if there is any way that my circuitry in the SAC box might be able to damage an fpga or USB chip pin that is needed for power-on autoconfigure but not used to separately load the fpga or access the flash. I had to study the schematics and other documents to learn what IO pins are used for power-on configuration, then see whether (and how) I might be using them.
Richard gave me his board to speed up my resumption of SAC Box debugging, since it will take some weeks roundtrip to get a replacement board from Ztex in Germany. Once the replacement comes in, I will return it to Richard.
No comments:
Post a Comment