My first breakthrough came after I began to doubt the truth of the claim in the documentation that this was adjusted to 'work with every Arduino'. In fact, the more I looked at the design, the more sure I was that it was only for the Arduino Uno and similar models, not the Arduino Mega 2560 that I was using.
Flashing the Uno with the provided program and plugging in the shield, I got much improved behavior right away. The serial port communication was erratic, but when I removed both NL and CR from the monitor session configuration, the results were appropriate. With NL and CR appended to my input lines, I got spurious complaints about D and A commands that I was not typing.
Using the W and R commands to read and write the 32 bit core, I discovered that only some of the memory is responding. With 8 bits, always the same positions or addresses, I can reliably write and read contents. However, figuring out from this how it pertains to the schematic is much much harder due to the Arduino code being used.
Specifically, the Arduino code reports using address 0 to 37 to address the 32 bits of core. My working bits are at address 8, 10, 11, 12, 14, 15, 25 and 29, judging by the binary address bits reported, but these don't correspond the 37 decimal. The code asks for hexadecimal values for block reads and writes, but I finally recognized that the address was octal, not decimal. 37 in octal is 31 decimal.
Until I can trace the addresses back to specific wires or components, I can't perform any corrective action. I tried laying out the cores in sequential order, either advancing horizontally fastest or vertically fastest, but neither offered illumination. In one of the orders, however, it did give a clue, or a suspicion that this has to do with one or more of the drive lines that have to coincide to flip a core.
If I number the cores, advancing vertically fastest, so that the left column is, from top to bottom 0, 1, 2, 3, 4, 5, 6 and 7, the next column begins at the top with 8 and proceeds down to 15, I see that the cores which work in the column 8-15 are the mirror of the cores that work in the column 24-31, while no cores work in the other two columns.
Tomorrow I will go over all the solder joints and continuity, after I dig into the VHDL and schematic to figure out which physical columns are the ones that partially work. I can begin watching signals with my oscilloscope as I read or write to specific locations. This is going to take time unless I spot some obvious construction flaw that can explain it all.
1401 SPURIOUS READ CHECKS
Our German 1401 system has been displaying erratic behavior when reading cards, with a variety of spurious errors being reported, mostly read checks. That error claims that the number of holes read by the Read Check brushes didn't match the number of holes read by the subsequent Read brushes. However, we saw this error even with completely blank cards,.
In some cases we received validity checks, asserting that the blank we just read was not a valid character. In other cases, the execution of the read command terminated with the CPU logic thinking it had not yet seen all 12 rows from the card.
These problems come and go. We can be scoping away trying to track down the fault when the machine decides to perform flawlessly for a while. Since the errors occur in several types, each triggered by different sets of logic, we can be watching gate A for a certain type of false read check when the machine begins throwing only the other types.
No comments:
Post a Comment