As you said there is a difference between Appendix B of H and I version of the App. Note.
As per your result, the troubleshooting steps are sinking with H version of the App. Note. Please follow the steps mentioned in H version as of now.
I will check internally and let you know the reasons for the change in I version.
I still have problems.
According to Document No. 001-76405 Rev. * H and Appendix B I have completed the following steps:
9.1.2 Synchronous ADMux Timing (ok)
- Hard reset FX3 and waiting >1S.
- Reading from PP_IDENTIFY (0x83) = 0x81.
- Reading from RD_MAILBOX2 (0x9C) = 0x5943, RD_MAILBOX3(0x9D) = 0x4257.
Appendix B. Troubleshooting Steps for Sync ADMux Boot
B.1 Initialization (ok)
- Write PP_INIT (0x81) = 0x0000;
- Write PP_CONFIG (0x82) = 0x0040;
B.2 Test Register Read/Write (ok)
- Write PP_SOCK_MASK_H (0x8B) = 0x0000;
- Write PP_SOCK_MASK_L (0x8A) = 0x0007;
- Write PP_INTR_MASK (0x88) = 0x2001;
B.3 Test FIFO Read/Write
1. Write a data pattern to the memory address 0x40003000 (ok):
a. Wait until bit 0 of PP_SOCK_STAT_L register (0x9E) is set (ok).
b. Write 0x0300 to the PP_DMA_XFER register (0x8E)(ok).
c. Wait until Bit 12 and Bit 15 of the PP_DMA_XFER register are set (ok).
d. Write 512 bytes of data with the following format to the FX3 device address 0 (SOCKET 0):
Byte 0 = 0x43
Byte 1 = 0x59
Byte 2 = 0x01 (write command)
Byte 3 = 0x7E
Byte 4 = 0x00 (LSB of address)
Byte 5 = 0x30
Byte 6 = 0x00
Byte 7 = 0x40 (MSB of address)
Bytes 8 to 511 can contain random data (I wrote 0x00) (ok).
2. Read back the status of the write operation:
a. Wait until bit 2 of PP_SOCK_STAT_L register (0x9E) is set(ok).
b. Write 0x0102 to the PP_DMA_XFER register (0x8E)(ok).
c. Wait until Bit 12 of the PP_DMA_XFER register is set(ok).
d. Read the PP_DMA_SIZE register (0x8F) and verify that the value is 0x0200(ok).
e. Read 512 bytes of data (256 cycles) from the FX3 address 0x02(ok).
f. Verify that the first four bytes contain the pattern 0x53, 0x42, 0x01, and 0x00 (error).
I have read 0x57, 0x42, 0x00, 0x00. The rest of 508 bytes = 0x00.
Where is my mistake?
The response data (0x57, 0x42, 0x00, 0x00) is fine.
The response byte is supposed to be 0x57 (Ascii value of W) , but not 0x53. This will be corrected in the next revision of the application note. The response  byte is don't care.
Please go ahead with testing the firmware download part (section B.4) and let us know the test result.
I have loaded the firmware in accordance with Document No. 001-76405 Rev. * H and Appendix B.4. But I have problems.
B.4 Test Firmware Download
2. Follow step 1 (i understand B.3.2) in FX3 Boot Options to write the following data to socket 0: 0x43, 0x59, 0x02, 0x01, ... (remaining 508 bytes are don’t care). (ок)
3. Follow step 2 (i understand B.3.2) in FX3 Boot Options to read the firmware download command status from socket 2. Verify that byte3 (status) has the value 0x00. (ок)
There are problems in section 4:
4. Now, write the complete firmware content to socket 1, 512 bytes at a time. Follow the procedure given below to write each 512 bytes to socket 1.
a. Wait until bit 1 of the PP_SOCK_STAT_L register (0x9E) is set.
b. Write 0x0301 to the PP_DMA_XFER register (0x8E).
c. Wait until Bit 12 and Bit 15 of the PP_DMA_XFER register are set.
d. Write 512 bytes of data to the FX3 device address 1.
My test firmware for FX3 has a size of 4464 bytes. After loading the first 512 bytes at a time, the PP_SOCK_STAT_L register (0x9E) is not set to 1 (B.4.4.a).
If in section B.4.2, write 0x43, 0x59, 0x02, 0x09 (number of data block 4464/512 = 8.71875 = 9), ...(the rest 508=0x00) - then all the firmware is downloaded, but it does not work.
If I download this firmware via USB, everything works. What am I doing wrong?
On page 27 (document No. 001-76405 Rev. * H) it is stated that:
- The data chunk of the bootloader image is not larger than 8K. For instance, on the command 0x02, the bLenStatus should not be larger than 16 blocks (8K bytes).
How to download the firmware if its size is 154000 bytes (> 8K)?
1) The data chunk size during the firmware download, is determined by the bLenStatus field of the boot command.
i.e, The "Enter Boot mode command (0x02)" for 512 bytes of data size (per transfer) should be as follows:
0x43, 0x59, 0x02, 0x01, ... (remaining 508 bytes are don’t care)
(Refer GPIF II API protocol table for details)
The length field (command ) of this command denotes the data chunk size per transfer and not the total firmware size.
When the length field is set as 0x09, the DMA_SIZE will change to 9*512 = 4608Bytes. The bootloader is designed to support only full packets. In your case, the data chunk size that the AP is sending to FX3 is 4464Bytes. This may be the reason why the firmware didn't work.
To fix this, you need to pad 4608 - 4464 = 144 bytes of zeros at the end of the firmware buffer.
2)"The data chunk of the bootloader image is not larger than 8K. For instance, on the command 0x02, the bLenStatus should not be larger than 16 blocks (8K bytes)".
The limitation stated above is about the DMA buffer size. The maximum DMA_SIZE that the bootloader supports is 8K and thus, the AP can send only 8K data (max) per transfer.
If the firmware size is greater than 8K , multiple transfers are needed to download the complete firmware to FX3.
i.e, step 4 of section B.4 should be repeated for each transfer until the complete firmware is transferred.
Please try the following:
a) The firmware buffer should be exactly same as the .img file. ( Note: Please do not use any other formats like .bin)
b) If the firmware size is not the multiple of the transfer size( DMA_SIZE) then additional zeros needs to padded at the end of the firmware buffer.
c) Refer the AP example code available in section 9.1.8 for understanding the firmware download sequence.
d) Please make sure that the socket 1 is available before any data transfer.
Note that the firmware download procedure steps mentioned in the application note AN76405 Rev. * H is based on 512 bytes of DMA buffer size.
I temporarily stopped working with ADMux.