FX3 Sync ADMux boot - data half missing

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
GrWh_4681056
Level 2
Level 2
Welcome!

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

0 Likes
1 Solution

To close the loop on this issue. According to Cypress

As for the Fx3 returning 2 words per read operation instead of one:
The behavior described is a known issue with the SYNC ADMux GPIF waveforms built into the boot-loader which gets exposed in specific conditions.
...
The work-around is to perform half the number of read operations. This should not affect the boot protocol as there is only one read operation and the data read back is not critical.

The only thing to be concerned about here is that the status/error readback (the 4th byte returned) will always report the same value as the 8th byte sent, so you would not get an error indication if your initial request message (4 bytes) was incorrect/not transmitted correctly.

So to underline the issues here and close the loop.  In AN76405 fx3_firmware_download(), if you have the double readback issue:

  1. sck_bootloader_write(CY 02 01) // socket request command
  2. sck_bootloader_read() // socket command response
  3. Check readback
  4. sck_bootloader_write(fw_data) // FW data transfer

If step 2 sees the double readback issue, but still iterates for all 512 bytes (call this overread) you will get an apparent write failure at step 4 - in this code of sck_bootloader_write() :
pastedImage_2.png

The workaround is to halve the readback count in sck_bootloader_read().

I hope this helps someone else experiencing the same problems.

View solution in original post

0 Likes
5 Replies
GrWh_4681056
Level 2
Level 2
Welcome!

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

0 Likes

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:

0 Likes

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

0 Likes

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?

0 Likes

To close the loop on this issue. According to Cypress

As for the Fx3 returning 2 words per read operation instead of one:
The behavior described is a known issue with the SYNC ADMux GPIF waveforms built into the boot-loader which gets exposed in specific conditions.
...
The work-around is to perform half the number of read operations. This should not affect the boot protocol as there is only one read operation and the data read back is not critical.

The only thing to be concerned about here is that the status/error readback (the 4th byte returned) will always report the same value as the 8th byte sent, so you would not get an error indication if your initial request message (4 bytes) was incorrect/not transmitted correctly.

So to underline the issues here and close the loop.  In AN76405 fx3_firmware_download(), if you have the double readback issue:

  1. sck_bootloader_write(CY 02 01) // socket request command
  2. sck_bootloader_read() // socket command response
  3. Check readback
  4. sck_bootloader_write(fw_data) // FW data transfer

If step 2 sees the double readback issue, but still iterates for all 512 bytes (call this overread) you will get an apparent write failure at step 4 - in this code of sck_bootloader_write() :
pastedImage_2.png

The workaround is to halve the readback count in sck_bootloader_read().

I hope this helps someone else experiencing the same problems.

0 Likes