When I got a chance during a very busy workday, I stopped by the workshop and looked into the circuit problems I found yesterday (driver circuit 40 and receiver circuit 18).
I also did some thinking about the problems loading the fpga bitstream into the flash on the Ztex board. While reviewing everything I did notice that the UCF entries for the flash, which are fpga pins that are also used for the data stream between PC and fpga logic, had a slightly different configuration.
I will change that configuration, reload the fpga and then try to load the bitstream again. At worst case, I will have the messages and sequences documented to post to the Ztex wiki. There are a few possibilities, such as the possibility that the flash chip is bad, but also the chance that it just needs an erasure or other special reset, or that there is a different problem. If the chip itself is bad, replacement is easy but diagnosis should be finished before I start removal and soldering on the fpga board.
The error continues - timeout trying to write to the flash chip. I might be able to check out the ability to read and write to the flash via the libjava library and the SDK API they offer, but it will take a bit more study.
At lunch hour I got to the machine, discovered that a trace was not connected on receiver circuit 18, and made a repair. However, my suspicion is that the chip serving driver circuits 37 to 41 is bad. i am whipping up a small board with a chip on it, to which I will hook up these circuits, which should at least validate the source of the problem. Construction took a little while, but then I was ready for the testing.
The results were still odd, which means I may have a problem in the 1131 or there is something unusual about these links. I removed one of the lines from the driver and checked its voltage levels - it was at SLT 3V! The pullup/terminator was operational on these four of the lines when I checked. I popped off the resistors on my driver board and these now behaved properly. I pulled one of the lines off a different chip on the driver board and found it too was pulled up just as I originally expected.
Somehow the four interrupt request lines were different, requiring drivers with pullup on my side, but the bulk of the other lines that are inbound to the 1131 are properly terminated and pulled to 3V. Time to go through these one by one and figure out a few things:
I will change that configuration, reload the fpga and then try to load the bitstream again. At worst case, I will have the messages and sequences documented to post to the Ztex wiki. There are a few possibilities, such as the possibility that the flash chip is bad, but also the chance that it just needs an erasure or other special reset, or that there is a different problem. If the chip itself is bad, replacement is easy but diagnosis should be finished before I start removal and soldering on the fpga board.
The error continues - timeout trying to write to the flash chip. I might be able to check out the ability to read and write to the flash via the libjava library and the SDK API they offer, but it will take a bit more study.
At lunch hour I got to the machine, discovered that a trace was not connected on receiver circuit 18, and made a repair. However, my suspicion is that the chip serving driver circuits 37 to 41 is bad. i am whipping up a small board with a chip on it, to which I will hook up these circuits, which should at least validate the source of the problem. Construction took a little while, but then I was ready for the testing.
The results were still odd, which means I may have a problem in the 1131 or there is something unusual about these links. I removed one of the lines from the driver and checked its voltage levels - it was at SLT 3V! The pullup/terminator was operational on these four of the lines when I checked. I popped off the resistors on my driver board and these now behaved properly. I pulled one of the lines off a different chip on the driver board and found it too was pulled up just as I originally expected.
Somehow the four interrupt request lines were different, requiring drivers with pullup on my side, but the bulk of the other lines that are inbound to the 1131 are properly terminated and pulled to 3V. Time to go through these one by one and figure out a few things:
- Which of these don't have pullup to 3V and may need the resistor on my end
- What is different about the lines that don't have pullup - card type?
- If all lines should have pullup, figure out what is wrong on the 1131 side.
It appears that the occurrences of lines without the pull-up to 3V is sporadic, no clear pattern but quite a few have this problem. If it were associated with all the bits of a given register, such as all the Channel Address Register bits, it might make sense, but at this point I have to assume there is a widespread failure of the pullup resistors on a variety of cards inside the 1131.
I will look at the system in future days to see whether it is feasible without high risk or effort to just replace the resistors on the cards. In some cases, IBM used resistor packs where one component implemented several resistors - that would make the task a bit harder since I am unlikely to find a ergonomically similar resistor pack. For the immediate purposes, I will just leave my pullups for any line that needs them.
I can use the resistance of the output from the driver board with the resistor hooked up to tell whether there is a pullup on the line or not - there are two cases, resistance around 66 ohms and up over 100. The low resistance indicates the pullup is in place on the 1131 end and I should remove my resistor.
When I straighten out the driver side issues, I can then go back to looking at the cycle steal requests, response and X clock signals. I found about 40% of the lines did not have a working pullup resistor, at least so far. I am about 3/5 of the way through all the circuits as the sun sets and I go back inside.
No comments:
Post a Comment