While I was debugging the general logic that I built to fire off a read of a target sector into the FIFO and then display it sequentially as bytes on the fpga board seven-segment displays, I decided to add in some additional logic to properly deal with the separate header and data fields in each sector.
The issue is that the drive resynchronizes between the two fields with a preamble of a couple hundred bits of zero, which means that I have to stop by byte assembly and resync to get the correct byte boundaries of the data field. Initially I just held the boundaries I established for the header field.
I know the byte count of a header field (and of a data field) - 5 and 257 respectively - following the preamble and sync byte for each. That was built into the FSM for reading so that it drops sync after storing byte five of the header, then begins again with the first payload byte of the data field.
Testing at lunchtime zoomed in on a couple of problems, which I corrected. By the end of my lunch hour I had the logic reading the five header bytes (cylinder high byte, cylinder low byte, combined platter/head/sector, CRC byte 1 and CRC byte 2).
I still have something zeroing out my FIFO so that I can't find any contents even though I received the five byte pulses that should have been stored. It may be my reset action between header and data fields, or it may be when I stop at the end of the sector. I will re-instrument and check again in the late afternoon.
I began designing a simple transactional communication method that would use the Digilent USB link and the Adept utility. With that in place, I should be able to drive this from the PC, setting up cylinder and sector targets, commanding seeks and reads, plus requesting bytes from the FIFO.
With that all prepared, I went out to the workshop and did some testing. I still have the undesirable behavior of the +5V Timer Board, powering down the drive after 6 minutes. This should only occur when the drive is idle and spun down (safe light on). I will need to do some circuit testing as this timeout is pretty annoying, introducing a whole cycle of stop and start which wastes minutes.
I also have communication between the PC and fpga board. I can command a read or seek and I see the FSMs kicking off, but they stall. While I have some defects, the ability to issue commands and check signal status via the PC is a great convenience.
I suspect either the 7400 or 7493 chip on the timer board - this is the logic that holds the decade counter in reset so that it never times out to shut off the main +5V supply. The 7400 is an extraordinarily basic (quad NAND) chip that for some reason I don't have in my pile of chips. The fact that I am missing the 7493 counter is less surprising but I do need that chip as well. My only option to grab those tonight, Frys, is a washout as they don't pretend to carry the 7400. They stock various other slightly incompatible family versions, e.g. 74ls00, 74hc00, and 74hct00.
I will drive to Anchor tomorrow morning to pick up the actual parts I need. Tonight I lifted the lead off the board from the driver (7400) chip that would hold the counter chip in reset, instead tacking a connection to ground to that circuit. I ran the drive for ten minutes without the timer shutting me down, so that makes the 7400 the suspect chip of the two, but I will pick up both as a preemptive measure.
Before I remove the bad chip, I took my remaining time tonight to debug my fpga controller logic a bit further. I could see that my read command was accepted and the main logic thought that it kicked off the sector read logic to search and match the target sector. However, something isn't correct in the sector read logic so my instrumentation moved to trace that portion of the logic.
Now with the next set of tracing, I see the read sector logic finding the proper sector number and turning on the final status where it is reading incoming bytes - however, the intermediate step which fires off the synchronizer seems not to occur - the scope wouldn't trigger on this status.
With that all prepared, I went out to the workshop and did some testing. I still have the undesirable behavior of the +5V Timer Board, powering down the drive after 6 minutes. This should only occur when the drive is idle and spun down (safe light on). I will need to do some circuit testing as this timeout is pretty annoying, introducing a whole cycle of stop and start which wastes minutes.
I also have communication between the PC and fpga board. I can command a read or seek and I see the FSMs kicking off, but they stall. While I have some defects, the ability to issue commands and check signal status via the PC is a great convenience.
I suspect either the 7400 or 7493 chip on the timer board - this is the logic that holds the decade counter in reset so that it never times out to shut off the main +5V supply. The 7400 is an extraordinarily basic (quad NAND) chip that for some reason I don't have in my pile of chips. The fact that I am missing the 7493 counter is less surprising but I do need that chip as well. My only option to grab those tonight, Frys, is a washout as they don't pretend to carry the 7400. They stock various other slightly incompatible family versions, e.g. 74ls00, 74hc00, and 74hct00.
I will drive to Anchor tomorrow morning to pick up the actual parts I need. Tonight I lifted the lead off the board from the driver (7400) chip that would hold the counter chip in reset, instead tacking a connection to ground to that circuit. I ran the drive for ten minutes without the timer shutting me down, so that makes the 7400 the suspect chip of the two, but I will pick up both as a preemptive measure.
Before I remove the bad chip, I took my remaining time tonight to debug my fpga controller logic a bit further. I could see that my read command was accepted and the main logic thought that it kicked off the sector read logic to search and match the target sector. However, something isn't correct in the sector read logic so my instrumentation moved to trace that portion of the logic.
Now with the next set of tracing, I see the read sector logic finding the proper sector number and turning on the final status where it is reading incoming bytes - however, the intermediate step which fires off the synchronizer seems not to occur - the scope wouldn't trigger on this status.
New instrumentation is in place but it is late tonight, so I will postpone further testing until tomorrow.
No comments:
Post a Comment