4 Replies Latest reply on Nov 22, 2020 7:06 PM by GrWh_4681056

    FX3 Sync ADMux boot - data half missing

    GrWh_4681056

      Following the steps in Appendix B we get to B.3

       

      Everything looks ok down to 2.f.  The returned data begins 57 42 00 30 - which at first blush looks like an error code (0x30), but looking deeper this is not the case.  Here is the buffer I'm sending:

       

                00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f  652d6de0: 43 59 01 7e 00 30 00 40 08 09 0a 0b 0c 0d 0e 0f   CY.~.0.@........ 652d6df0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 652d6e00: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 652d6e10: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 652d6e20: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO 652d6e30: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_ 652d6e40: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno 652d6e50: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~. 652d6e60: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................ 652d6e70: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................ 652d6e80: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................ 652d6e90: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................ 652d6ea0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................ 652d6eb0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................ 652d6ec0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................ 652d6ed0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................ 652d6ee0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f   ................ 652d6ef0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 652d6f00: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 652d6f10: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 652d6f20: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO 652d6f30: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_ 652d6f40: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno 652d6f50: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~. 652d6f60: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................ 652d6f70: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................ 652d6f80: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................ 652d6f90: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................ 652d6fa0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................ 652d6fb0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................ 652d6fc0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................ 652d6fd0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................

       

      The socket response is

                00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f  652d7010: 57 42 00 30 08 09 0c 0d 10 11 14 15 18 19 1c 1d   WB.0............ 652d7020: 20 21 24 25 28 29 2c 2d 30 31 34 35 38 39 3c 3d    !$%(),-014589<= 652d7030: 40 41 44 45 48 49 4c 4d 50 51 54 55 58 59 5c 5d   @ADEHILMPQTUXY\] 652d7040: 60 61 64 65 68 69 6c 6d 70 71 74 75 78 79 7c 7d   `adehilmpqtuxy|} 652d7050: 80 81 84 85 88 89 8c 8d 90 91 94 95 98 99 9c 9d   ................ 652d7060: a0 a1 a4 a5 a8 a9 ac ad b0 b1 b4 b5 b8 b9 bc bd   ................ 652d7070: c0 c1 c4 c5 c8 c9 cc cd d0 d1 d4 d5 d8 d9 dc dd   ................ 652d7080: e0 e1 e4 e5 e8 e9 ec ed f0 f1 f4 f5 f8 f9 fc fd   ................ 652d7090: 00 01 04 05 08 09 0c 0d 10 11 14 15 18 19 1c 1d   ................ 652d70a0: 20 21 24 25 28 29 2c 2d 30 31 34 35 38 39 3c 3d    !$%(),-014589<= 652d70b0: 40 41 44 45 48 49 4c 4d 50 51 54 55 58 59 5c 5d   @ADEHILMPQTUXY\] 652d70c0: 60 61 64 65 68 69 6c 6d 70 71 74 75 78 79 7c 7d   `adehilmpqtuxy|} 652d70d0: 80 81 84 85 88 89 8c 8d 90 91 94 95 98 99 9c 9d   ................ 652d70e0: a0 a1 a4 a5 a8 a9 ac ad b0 b1 b4 b5 b8 b9 bc bd   ................ 652d70f0: c0 c1 c4 c5 c8 c9 cc cd d0 d1 d4 d5 d8 d9 dc dd   ................ 652d7100: e0 e1 e4 e5 e8 e9 ec ed f0 f1 f4 f5 f8 f9 fc fd   ................ 652d7110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

       

      Note that 57 42 00 30 is clearly result of the omission of every second 16-bit word.  This is (probably) confirmed by performing the read-back step (B.3 steps 3-4), which reads back the RAM showing the same (half) data as was sent/received before.

       

      For this appendix B testing I'm using the example sck_bootloader_write() and sck_bootloader_read() functions, adding any extra status polling suggested by Appendix B.

       

      To diagnose this further I modified the transmit message function to send each word twice:

       

              for (i = 0; i < (buf_sz / 2); i++)         {             IOWR_SCK16(*p);             IOWR_SCK16(*p++); /* Write 512 bytes of data continuously to data socket 16                                  bits at a time ( Sync ADMux has 16 data lines) */         }

       

      This resulted in the following data returned on the socket read:

                00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f  652d7018: 57 42 01 7e 00 30 00 40 08 09 0a 0b 0c 0d 0e 0f   WB.~.0.@........ 652d7028: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................ 652d7038: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./ 652d7048: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>? 652d7058: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO 652d7068: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_ 652d7078: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno 652d7088: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~. 652d7098: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................ 652d70a8: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................ 652d70b8: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................ 652d70c8: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................ 652d70d8: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................ 652d70e8: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................ 652d70f8: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................ 652d7108: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................ 652d7118: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7128: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7138: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7148: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7158: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7168: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7178: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7188: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7198: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71a8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71b8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71c8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71e8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d71f8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................ 652d7208: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

       

      This looks like the transmission halted after 512 words, but only accepted every second word.

       

      Any thoughts on how to proceed?

       

      I've looked through other questions - which might have similar responses, but were discontinued:

       

      Sync ADMux Boot

       

      or old

       

      FX3 Sync ADMUX boot problem

        • 1. Re: FX3 Sync ADMux boot - data half missing
          GrWh_4681056

          argh - looks like the HTML editor has broken my code and hex-dumps

          • 2. Re: FX3 Sync ADMux boot - data half missing
            GrWh_4681056

            Following the steps in Appendix B we get to B.3

             

            Everything looks ok down to 2.f.  The returned data begins 57 42 00 30 - which at first blush looks like an error code (0x30), but looking deeper this is not the case.  Here is the buffer I'm sending:

             

                      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
            652d6de0: 43 59 01 7e 00 30 00 40 08 09 0a 0b 0c 0d 0e 0f   CY.~.0.@........
            652d6df0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................
            652d6e00: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./
            652d6e10: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>?
            652d6e20: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO
            652d6e30: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_
            652d6e40: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno
            652d6e50: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~.
            652d6e60: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................
            652d6e70: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................
            652d6e80: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................
            652d6e90: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................
            652d6ea0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................
            652d6eb0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................
            652d6ec0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................
            652d6ed0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................
            652d6ee0: 00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f   ................
            652d6ef0: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................
            652d6f00: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./
            652d6f10: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>?
            652d6f20: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO
            652d6f30: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_
            652d6f40: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno
            652d6f50: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~.
            652d6f60: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................
            652d6f70: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................
            652d6f80: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................
            652d6f90: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................
            652d6fa0: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................
            652d6fb0: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................
            652d6fc0: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................
            652d6fd0: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................

             

            The socket response is

                      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
            652d7010: 57 42 00 30 08 09 0c 0d 10 11 14 15 18 19 1c 1d   WB.0............
            652d7020: 20 21 24 25 28 29 2c 2d 30 31 34 35 38 39 3c 3d    !$%(),-014589<=
            652d7030: 40 41 44 45 48 49 4c 4d 50 51 54 55 58 59 5c 5d   @ADEHILMPQTUXY\]
            652d7040: 60 61 64 65 68 69 6c 6d 70 71 74 75 78 79 7c 7d   `adehilmpqtuxy|}
            652d7050: 80 81 84 85 88 89 8c 8d 90 91 94 95 98 99 9c 9d   ................
            652d7060: a0 a1 a4 a5 a8 a9 ac ad b0 b1 b4 b5 b8 b9 bc bd   ................
            652d7070: c0 c1 c4 c5 c8 c9 cc cd d0 d1 d4 d5 d8 d9 dc dd   ................
            652d7080: e0 e1 e4 e5 e8 e9 ec ed f0 f1 f4 f5 f8 f9 fc fd   ................
            652d7090: 00 01 04 05 08 09 0c 0d 10 11 14 15 18 19 1c 1d   ................
            652d70a0: 20 21 24 25 28 29 2c 2d 30 31 34 35 38 39 3c 3d    !$%(),-014589<=
            652d70b0: 40 41 44 45 48 49 4c 4d 50 51 54 55 58 59 5c 5d   @ADEHILMPQTUXY\]
            652d70c0: 60 61 64 65 68 69 6c 6d 70 71 74 75 78 79 7c 7d   `adehilmpqtuxy|}
            652d70d0: 80 81 84 85 88 89 8c 8d 90 91 94 95 98 99 9c 9d   ................
            652d70e0: a0 a1 a4 a5 a8 a9 ac ad b0 b1 b4 b5 b8 b9 bc bd   ................
            652d70f0: c0 c1 c4 c5 c8 c9 cc cd d0 d1 d4 d5 d8 d9 dc dd   ................
            652d7100: e0 e1 e4 e5 e8 e9 ec ed f0 f1 f4 f5 f8 f9 fc fd   ................
            652d7110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             

            Note that 57 42 00 30 is clearly result of the omission of every second 16-bit word.  This is (probably) confirmed by performing the read-back step (B.3 steps 3-4), which reads back the RAM showing the same (half) data as was sent/received before.

             

            For this appendix B testing I'm using the example sck_bootloader_write() and sck_bootloader_read() functions, adding any extra status polling suggested by Appendix B.

             

            To diagnose this further I modified the transmit message function to send each word twice:

             

                    for (i = 0; i < (buf_sz / 2); i++)
                    {
                        IOWR_SCK16(*p);
                        IOWR_SCK16(*p++); /* Write 512 bytes of data continuously to data socket 16
                                             bits at a time ( Sync ADMux has 16 data lines) */
                    }

             

             

            1.         for (i = 0; i < (buf_sz / 2); i++)        {            IOWR_SCK16(*p);            IOWR_SCK16(*p++); /* Write 512 bytes of data continuously to data socket 16                                  bits at a time ( Sync ADMux has 16 data lines) */        } 

             

            This resulted in the following data returned on the socket read:

                      00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
            652d7018: 57 42 01 7e 00 30 00 40 08 09 0a 0b 0c 0d 0e 0f   WB.~.0.@........
            652d7028: 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f   ................
            652d7038: 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f    !"#$%&'()*+,-./
            652d7048: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f   0123456789:;<=>?
            652d7058: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f   @ABCDEFGHIJKLMNO
            652d7068: 50 51 52 53 54 55 56 57 58 59 5a 5b 5c 5d 5e 5f   PQRSTUVWXYZ[\]^_
            652d7078: 60 61 62 63 64 65 66 67 68 69 6a 6b 6c 6d 6e 6f   `abcdefghijklmno
            652d7088: 70 71 72 73 74 75 76 77 78 79 7a 7b 7c 7d 7e 7f   pqrstuvwxyz{|}~.
            652d7098: 80 81 82 83 84 85 86 87 88 89 8a 8b 8c 8d 8e 8f   ................
            652d70a8: 90 91 92 93 94 95 96 97 98 99 9a 9b 9c 9d 9e 9f   ................
            652d70b8: a0 a1 a2 a3 a4 a5 a6 a7 a8 a9 aa ab ac ad ae af   ................
            652d70c8: b0 b1 b2 b3 b4 b5 b6 b7 b8 b9 ba bb bc bd be bf   ................
            652d70d8: c0 c1 c2 c3 c4 c5 c6 c7 c8 c9 ca cb cc cd ce cf   ................
            652d70e8: d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 da db dc dd de df   ................
            652d70f8: e0 e1 e2 e3 e4 e5 e6 e7 e8 e9 ea eb ec ed ee ef   ................
            652d7108: f0 f1 f2 f3 f4 f5 f6 f7 f8 f9 fa fb fc fd fe ff   ................
            652d7118: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7128: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7138: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7148: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7158: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7168: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7178: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7188: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7198: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71a8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71b8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71c8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71d8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71e8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d71f8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
            652d7208: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

             

            This looks like the transmission halted after 512 words, but only accepted every second word.

             

            Any thoughts on how to proceed?

             

            I've looked through other questions - which might have similar responses, but were discontinued:

            • 3. Re: FX3 Sync ADMux boot - data half missing
              YatheeshK_36

              Hello,

               

              As mentioned under the note section in page 57 of Application note: https://www.cypress.com/file/201991/download 

               

              “If the correct response is not received while reading back the status of the write operation, read 256 bytes of data (128 cycles) from the FX3 Response Socket (address 0x02) instead of 512 bytes.

               

              Thanks,

              Yatheesh

              • 4. Re: FX3 Sync ADMux boot - data half missing
                GrWh_4681056

                Thanks for your response.

                 

                “If the correct response is not received while reading back the status of the write operation, read 256 bytes of data (128 cycles) from the FX3 Response Socket (address 0x02) instead of 512 bytes.

                 

                I have reduced the readback size - terminating the read early - in the case the second word contains a non-zero error code.  This doesn't change any other behaviour however.  The reason I don't think this is relevant is because:

                1. It doesn't explain why the original write would be in error
                2. and I don't trust the 4th byte in the response message

                 

                In the examples I posted I saw "57 42 00 30" - - which looks like an error, but also looks like a word has been skipped.  in the "Read-back" command returned data "57 42 01 7e" that shows the second word is simply a repeat of what was sent when creating the read-back command (cmd = 01, lentgh=7e (512)).  And that only occurred when double-sending otherwise I got "00 30" - skipped that word.

                 

                To prove this I moved the memory read address to 0x40003100:

                tx[0] = 'C';
                tx[1] = 'Y';
                tx[2] = 0x1;
                tx[3] = 0x7e;
                tx[4] = 0x00;
                tx[5] = 0x31;
                tx[6] = 0x00;
                tx[7] = 0x40;

                and readback command

                tx[0] = 'C';
                tx[1] = 'Y';
                tx[2] = 0x3;
                tx[3] = 0x7e;
                tx[4] = 0x00;
                tx[5] = 0x31;
                tx[6] = 0x00;
                tx[7] = 0x40;

                 

                In the readback of the write command, and the read-back of the read-command I got "57 42 00 31" as the response - ie the device is just looping the address bytes back into that place - it is not the error 0x31 - it is simply the address byte.

                 

                 

                New investigation - Burst size

                I've found one way I can change the response (slightly) - and that is if I perform the same steps, but write PP_CONFIG = 0x41 (burst size = 1), I then receive responses with every third word included instead of every second - eg: here is a readback with burst size = 1

                 

                          00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 
                652d7218: 57 42 00 40 0c 0d 12 13 18 19 1e 1f 24 25 2a 2b   WB.@........$%*+
                652d7228: 30 31 36 37 3c 3d 42 43 48 49 4e 4f 54 55 5a 5b   0167<=BCHINOTUZ[
                652d7238: 60 61 66 67 6c 6d 72 73 78 79 7e 7f 84 85 8a 8b   `afglmrsxy~.....
                652d7248: 90 91 96 97 9c 9d a2 a3 a8 a9 ae af b4 b5 ba bb   ................
                652d7258: c0 c1 c6 c7 cc cd d2 d3 d8 d9 de df e4 e5 ea eb   ................
                652d7268: f0 f1 f6 f7 fc fd 02 03 08 09 0e 0f 14 15 1a 1b   ................
                652d7278: 20 21 26 27 2c 2d 32 33 38 39 3e 3f 44 45 4a 4b    !&',-2389>?DEJK
                652d7288: 50 51 56 57 5c 5d 62 63 68 69 6e 6f 74 75 7a 7b   PQVW\]bchinotuz{
                652d7298: 80 81 86 87 8c 8d 92 93 98 99 9e 9f a4 a5 aa ab   ................
                652d72a8: b0 b1 b6 b7 bc bd c2 c3 c8 c9 ce cf d4 d5 da db   ................
                652d72b8: e0 e1 e6 e7 ec ed f2 f3 f8 f9 fe ff 00 00 00 00   ................
                ........

                 

                So it is clear to me that something related to bursting is involved - if I could set BURSTsize to "-1" we would be in business.

                I've checked that DRQMODE == 0 (I've also tried setting it to 1), since burstmode is supposed to be ignored if DRQMODE == 0.  Its not clear to me what DACK is referring to - is that an alias for some other bit on the sync AD-Mux?