diff --git a/attic/on-wire-protocol-notes.txt b/attic/on-wire-protocol-notes.txt new file mode 100644 index 0000000000000000000000000000000000000000..d44b621e40d30dc2cf1acdfac9bb218c5f24d420 --- /dev/null +++ b/attic/on-wire-protocol-notes.txt @@ -0,0 +1,174 @@ +Genearl Procedure: + +Watch the signal. + -> One wire + -> Measure timing + -> Count bulk numbers of bits? + -> Is it encoded funny + -> Same timing for several bits? + -> Same number of edges for bits? + -> Write out 1's and 0's + -> Find a "counting" thing to discover MSBit first. + -> Write it out in Notepad++ + -> Look for which bits change and which ones don't. + -> Seeing slight variations on timing to identify whether it's host or client talking. + This is with Part ID 20-9e-ab-cd-88-b3-bc-48 << + -> By knowing the part ID we can search for it in what we think are the replies from the chip. + -> Once found we can make more sense of the rest of the protocol. + -> Also, look at the USB protocol to the WCH-Link + -> Ok, that was worthless. + -> Try running the programmer without a processor connected. + -> wow! Turns out the processor doesn't "send data back" + -> Instead, the host drives a line low then goes high-z + -> Then the chip decides to "drive the line high" if it's a 1. + + +There is an initial training pattern. + +Start with line high. + +FIRST: + low for 8.2us + high for 3.1us + low for 9.2us + high for 3.1us + low for 102.3us + high for 95.3us + +Then repeat this, 199 times + low for 4.07s + high for 3.1us + low for 8.26us + high for 3.1us + low for 9.3us + high for 3.1us + low for 102.3us + high for 95.1us + +Then, repeat this 10x + low for 4.1us + high for 210us + low for 6.3us + high for 2us + low for 8.4us + high for 2us + low for 6.2us + high for 2.4us + low for 5.2us + high for 2.1us + low for 62.3us + high for 2.1us + low for 8.5us + high for 5.3us + low for 2us + high for 8.4us + low for 6.3us + high for 2.1us + low for 8.4us + high for 2.1us + low for 6.9us + high for 1.7us + low for 5.3us + high for 2.1us + low for 63.3us + high for 2.1us + low for 8.4us + high for 5.3us + low for 2us + high for 5.8us + low for 6.3us + high for 2.1us + low for 6.3us + high for 2.1us + low for 8us + high for 1.6us + low for 6.6us + high for 80us + +low for 2us +high for 5.3us + +then the break. + + +*** 2ms low break *** + + +line goes high for 620ns and BOOM we begin our session. + +Then, there is a one-wire like protocol for data comms. Thanks, Spirit. + +Sending data goes: + 0: on-for-250-ns off-for-1000-ns + 1: on-for-250-ns off-for-250-ns + +For replies from the processor: + The clocking is still controlled by the host. + The host drives the line low, goes high Z with pull-up. + The processor can drive the line low for this period to indicate a 0. + 0: on-for-320us off-for-790ns / Total: 1100ns + 1: on-for-320us off-for-420ns / Total: 740ns + + +"/" indicates flip to chip instead of programmer + +Then the data starts. + +"Issue Chip Reset": + +11 1111101 01011010 10100101 00000100 00000000 +11 1111011 01011010 10100101 00000100 00000000 +11 1111000/00000000 00000001 00000100 00000011 << I thought this was "turned around" but it seems the main uc controls the clocking and it's up to the uc to drive high. +10 0100010/00000000 01001111 00000011 10000010 +10 0100001 10000000 00000000 00000000 00000001 +10 0100001 10000000 00000000 00000000 00000001 +10 0101100/00001000 00000000 00000000 00000010 +-- +10 0100010/00000000 01001111 00000011 10000010 +11 1111110/00000000 00110000 00000101 00000000 +10 0001011 00011111 11111111 11110111 11000100 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/00000000 00110000 00000101 00000000 +10 0001001 00000000 00000000 00000011 00000111 +10 0101111 00000000 00100011 00000111 11000000 +-- +10 0001011 00011111 11111111 11110111 11100000 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/11111111 11111111 00000000 00010000 <<<< CAPACITY First 4 bytes of the response from "\x81\x11\x01\x09" +10 0001011 00011111 11111111 11110111 11101000 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/00100000 10011110 10101011 11001101 <<<< CHIP UID +10 0001011 00011111 11111111 11110111 11101100 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/10001000 10110011 10111100 01001000 <<<< CHIP UID +10 0001011 00011111 11111111 11110111 11110000 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/00000000 00000000 00000000 00000000 *** UNSURE ABOUT THIS LINE >> Actually probably all 1's *** +10 0001011 00011111 11111111 11110111 11000100 +10 0101111 00000000 00000100 00000000 00000000 +10 0001000/00000000 00110000 00000101 00000000 + +10 0100010 00000000 01001111 00000011 10000010 +10 0100011 00000000 00000000 00000000 00000001 +10 0100001 10000000 00000000 00000000 00000001 +10 0101100 00001000 00000000 00000000 00000010 + +10 0100010 00000000 01001111 00000011 10000010 +10 0001011 11100000 00000000 11100000 01001000 +10 0001001 10111110 11101111 00000000 10000000 +10 1000001 01111011 00100101 00010000 01110011 +10 1000011 01111011 00110101 10010000 01110011 +10 1000101 11100000 00000000 00000101 00110111 +10 1000111 00001111 10000101 00100101 10000011 +10 1001011 00100101 01110011 11000001 10001000 +10 1001101 00100101 11110011 01111011 00100000 +10 1001111 10010000 00000010 01111011 00110000 +10 0101111 00000000 00000100 00000000 00000000 + + +wch_link_command( devh, "\x81\x0d\x01\xff", 4, 0, 0, 0); +10 0100001 01000000 00000000 00000000 00000001 +10 0100001 01000000 00000000 00000000 00000000 +10 0100010 00000000 01001100 00001100 10000010 + +