Sunday, April 12, 2015

Homing in on last issues with cycle steal addressing and the basic bidirectional USB link from SAC Interface box to PC program


I posted a question to the maker of the Ztex fpga board before I rework the board to replace the SPI flash - since it may be a logical state that I can correct without desoldering and changing the chip. I will wait a few days to see if there is a simple fix before I order a replacement flash chip.

I spent a couple of hours exhaustively testing each Channel Address In bit for cycle steal store and determined that bits 8, 12 and 15 are always read as 0, regardless of the value I believe I am emitting. These are the three bit positions that were bad previously when I thought I had fixed things moving over to spare gates.

My next move was to electrically test these while they should be set to 1. I found them to correctly sit at 0 when they should be off, but I didn't test the other condition when they should float up to 1. As the results had hinted, these lines were frozen down at 0 regardless of the input for two of them, and the third a funny input. Grrrr. All three of these are on the same card in the 1131, thus if I find the problem is here, I can swap with the card handling bits 0 to 7 to see if it floats with the card.

I wasn't happy with the logic for the fpga side of the link, the part that writes words or reads them. I isolated this from the transactional FSM and the output FSMs, which should make debugging of the link operation easier. The first instantiation was a simple echo function, so that whatever was written to the fpga on endpoint 6 would be written back on endpoint 2.

If the Python program couldn't write words and read them back correctly, the problem was likely on the PC side not with fpga logic. I ran out of time to test them due to family obligations, but I can get to this during the coming week. 

No comments:

Post a Comment