Gregory's Serveri thought it might be a timing issue caused by disabling USB debugging, but it still happens (with roughly the same statistics) with USB debugging turned on.
|
12 comments
 also -- there seem to be two overlapping bugs. one causes a few bits to be corrupted for single sector reads, the other causes an entire sector's data to be shifted by several bytes.  huh, once I connect the logic analyzer, the problem takes much longer to reproduce; the probability of data corruption drops dramatically. interesting but it makes things much harder to debug. @tubetime hey @azonenberg weren’t you looking for examples of probes changing behavior of the DUT? looks like it is skipping a transfer here somehow. it transfers B66D, then it skips 6DDB and goes to DBB6. the preempt line seems to deassert right before arb/gnt goes high. that doesn't seem right.  @tubetime A coincidence that DBB6 == 6DDB << 1 ? Could it be slipping a bit? @jond no that is just the pattern in the disk image. presumably a disk area that was never written to after being formatted and still contains this bit pattern. the smoking gun: an invalid bus transfer. both rd and wr are asserted at the same time. before that we see the missing data on the bus: 6DDB. so the card thinks it is in a DMA cycle even though it is not, and it's putting data on the bus when it shouldn't be! i deleted 3 characters from my verilog and it works now. 😅 (i still need to test writes, and i need to test it without the logic analyzer card) @tubetime As the joke goes, its all about knowing where to tap...  @tubetime Ugh, that's NEVER good. I see lots of oscilloscope probing in your future. |
looks like some individual data bits are getting flipped. what's really odd is that it is repeatable and it seems to be the same bits at the same addresses.