The board maker sent a modified version of the SDK library with a longer timeout, which I will try to test whether it resolves the failures writing to the flash. It did not make a different. I have a few possible resolutions:
- rework the board to replace the SPI flash chip
- send the board back for a replacement
- build a board to sit on the JTAG lines, hold the bit image and initialize the fpga at startup
If the problem with the timeout is the flash chip itself, my rework will fix the problem. However, if it is a problem with traces on the board or a failure in the USB chip, the change won't resolve the failure.
It takes a few weeks to send the board back and forth to Germany, at least at any reasonable postage rate. It would probably be more cost effective to simply order a second board and eventually swap it into the box when it arrives.
I am assuming I can get access to the JTAG lines from my board, but I haven't researched it fully. Since FPGAs normally load their bitimage over JTAG at startup, this is a reasonable method although it may be complicated to write each changed image to the daughter board I would build to provide the new function.
I ordered a couple of the flash chips from Digikey, because as I read the data sheets for the chip, it became clear that it has modes where it can protect portions from writing yet resetting the configuration to factory default state is not possible. My chip may be wedged in some strange state, even though it is otherwise functional.
There are several resistors and other components nearby the flash chip, which would require good shielding before I used my heat gun to remove the flash chip. On the other hand, I can snip off the eight leads, remove the chip, then clean off the remnants of the leads using my small tip on the soldering iron. That would allow me to solder the replacement chip into place while having avoided any desoldering or heat damage to adjacent parts.
 |
| SPI Flash chip to be removed and replaced with new stock |
I found and fixed the partition of my ground network inside the SAC Interface Box. Testing resumed on Friday lunchtime, when I had a chance to begin checkout of the newly built driver board. In short order I discovered a wisp of ground wire blocking one of the Channel Address In bits, corrected it, and then confirmed that all Channel Address In bits are working correctly. In addition, all the Channel Data In bits are working. Further, interrupt request, cycle steal and other lines are good.
I tested this by repeated Cycle Steal Store operations to a succession of addresses to test out each address bit, from time to time varying the bit pattern that was stored in order to validate the data lines at the same time. Once that was complete, I had the processor execute one instruction, XIO Sense DSW to my pseudo device at area code 21 (decimal), which received my status word 0x1130 in the accumulator.
It is time to work on two different sets of tests. One will test the pseudo-device for its operation with XIO Read, XIO Write and XIO Control. The other will work on establishing the PC transactional link allowing me to transfer control and data signals needed to emulate any peripheral from the PC. It will also give me the means to load and dump the contents of core storage on the 1131 to the PC.
I am working through my XIO Read logic - which did not store the value I expected into storage at the target address I intended. I am reviewing the logic for the function in preparation for some diagnostic testing. All I know at this point is that I am not emitting the Channel Data In values nor setting the Channel Write Gate. This would be symptomatic of an FSM failure, either the FSM in the XIO Read module or the shadowing routine that should be recording when I am in the various E phases of an XIO.
While mildly annoying, this is exactly the sort of debugging I should be doing, with the basic receiving/driving of signals to the 1131 now solid.
I tested this by repeated Cycle Steal Store operations to a succession of addresses to test out each address bit, from time to time varying the bit pattern that was stored in order to validate the data lines at the same time. Once that was complete, I had the processor execute one instruction, XIO Sense DSW to my pseudo device at area code 21 (decimal), which received my status word 0x1130 in the accumulator.
It is time to work on two different sets of tests. One will test the pseudo-device for its operation with XIO Read, XIO Write and XIO Control. The other will work on establishing the PC transactional link allowing me to transfer control and data signals needed to emulate any peripheral from the PC. It will also give me the means to load and dump the contents of core storage on the 1131 to the PC.
I am working through my XIO Read logic - which did not store the value I expected into storage at the target address I intended. I am reviewing the logic for the function in preparation for some diagnostic testing. All I know at this point is that I am not emitting the Channel Data In values nor setting the Channel Write Gate. This would be symptomatic of an FSM failure, either the FSM in the XIO Read module or the shadowing routine that should be recording when I am in the various E phases of an XIO.
While mildly annoying, this is exactly the sort of debugging I should be doing, with the basic receiving/driving of signals to the 1131 now solid.
No comments:
Post a Comment