{"action":"opened","issue":{"url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware/issues/12","repository_url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware","labels_url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware/issues/12/labels{/name}","comments_url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware/issues/12/comments","events_url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware/issues/12/events","html_url":"https://github.com/diamondman/adapt-xpcusb-firmware/issues/12","id":180587655,"number":12,"title":"Figure out why wrong amount of data is returned in some situations","user":{"login":"diamondman","id":1037510,"avatar_url":"https://avatars.githubusercontent.com/u/1037510?v=3","gravatar_id":"","url":"https://api.github.com/users/diamondman","html_url":"https://github.com/diamondman","followers_url":"https://api.github.com/users/diamondman/followers","following_url":"https://api.github.com/users/diamondman/following{/other_user}","gists_url":"https://api.github.com/users/diamondman/gists{/gist_id}","starred_url":"https://api.github.com/users/diamondman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/diamondman/subscriptions","organizations_url":"https://api.github.com/users/diamondman/orgs","repos_url":"https://api.github.com/users/diamondman/repos","events_url":"https://api.github.com/users/diamondman/events{/privacy}","received_events_url":"https://api.github.com/users/diamondman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/diamondman/adapt-xpcusb-firmware/labels/bug","name":"bug","color":"fc2929"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-10-03T08:35:53Z","updated_at":"2016-10-03T08:35:53Z","closed_at":null,"body":"In every 16 bit block of data to the arbitrary write command of the XPCU1 controller, 4 bits specify if the clock should be toggled, and 4 bits specify if bits should be read. \r\n\r\nIn many hard to predict situations when reading back more than 32 bits. It also appears to happen sometimes when reading some data, but it is hard to tell when. Some relation to reading or clocking a number of bits that are divisible by 4 seem related. \r\n\r\nThe results are 'consistent' (in that in all tried cases, things break the same way despite having no clear rule) between open firmware and proprietary firmware. The open firmware does not deal directly with loading bits into the return USB buffer (as that is handled by the GPIF waveform automatically) so it is likely to be an issue in the CPLD's firmware. \r\n\r\n\r\n## EXAMPLE OF CLK bits acting strange\r\n```\r\nh.controlWrite(0x40, 0xB0, 0xA6, 36-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\xff\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\x0f\\xff')\r\ntryread() \r\nff ff ff ff 00 f0\r\n\r\nh.controlWrite(0x40, 0xB0, 0xA6, 36-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\xee\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\x0f\\xff')\r\ntryread()\r\nff ff ff ff\r\n```\r\n## EXAMPLE OF TDO bits acting strange:\r\n```\r\n#Reading 36 bits of data\r\nh.controlWrite(0x40, 0xB0, 0xA6, 36-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\xff\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\xf0\\xff')\r\ntryread()\r\nff ff ff ff 00 f0 #reads back 5 real data bytes (plus 6th 0 byte as specified in adapt docs). This is correct.\r\n\r\n#Reading 35 bits (the 0x7f in the beginning of the string is the extra 3 bits)\r\nh.controlWrite(0x40, 0xB0, 0xA6, 36-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\x7f\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\xf0\\xff')\r\ntryread()\r\nff ff ff ff #returns 32 bits of data (Wrong! Should get 6 bytes like above)\r\n\r\n#Reading 34 bits out of 40\r\nh.controlWrite(0x40, 0xB0, 0xA6, 40-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\x1f\\xf0\\x1f\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\xf0\\xff')\r\ntryread()\r\nff ff ff ff #FAILURE AGAIN\r\n\r\n#Reading 35 bits out of 40 (3 bits from the 7 and the 1 bit from the 1 sum to 3 so it works....)\r\nh.controlWrite(0x40, 0xB0, 0xA6, 40-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\x7f\\xf0\\x1f\\xf0\\xff\\xf0\\xFF\\xF0\\xFF\\x0f\\xff\\xf0\\xFF\\xf0\\xff\\xf0\\xff\\xf0\\xff')\r\ntryread()\r\nff ff ff ff 00 f0 #Works! If only it worked the other 3/4 times\r\n```\r\n\r\nSometimes random TDO bits actually works correctly. A solution to figuring out what is happening might be to try to rip apart the CPLD firmware. But if that is not doable, enough data has been collected to build a new firmware from scratch without the rarely used extra modes.\r\n\r\n\r\nExtra code that was used above.\r\n\r\n```\r\n#Initialize controller\r\nfrom proteusisc.bittypes import CompositeBitarray, NoCareBitarray, ConstantBitarray; from bitarray import bitarray;from proteusisc import getAttachedControllers;xil = getAttachedControllers(\"PC1_0000\")[0];xil.jtag_enable(); h = xil._handle\r\n\r\n#Do reads and check for weird possible issues\r\ndef tryread():\r\n    import time\r\n    time.sleep(.1)\r\n    print(h.bulkRead(6, 8, timeout=250).hex())\r\n    try: \r\n        print(\"EXTRA\", h.bulkRead(6, 8, timeout=250).hex())#b'\\xfc\\xff'\r\n    except Exception as e:\r\n        pass\r\n\r\n#Change controller to SHIFTDR and read out 32 bits... loading into the DR 0x55555555\r\nh.controlWrite(0x40, 0xB0, 0xA6, 41-1, b'')\r\nh.bulkWrite(2, b'\\xf0\\x0F\\x50\\x0f\\x0a\\xef\\x0a\\xff\\x0a\\xff\\x0a\\xff\\x0a\\xff\\x0a\\xff\\x0a\\xff\\x0a\\xff\\x00\\x11')\r\ntryread()\r\n\r\n#Read 32 bits of data\r\nh.controlWrite(0x40, 0xB0, 0xA6, 32-1, b'')\r\nh.bulkWrite(2, b'\\x05\\xff'*8)\r\ntryread()\r\n```"}}
{"actor":{"display_login":"diamondman"}}