Sync ADMux Boot

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

cross mob
Anonymous
Not applicable

I have problems with firmware download from a host processor to FX3 through the 16-bit synchronous ADMux interface. I use Document No. 001-76405 Rev. * I.

You updated Appendix B: Troubleshooting Steps for Sync ADMux Boot in the document No. 001-76405 Rev. * I

In which you specify to write 256 bytes of data (B.3.1.d). Is not this a mistake? In Document No. 001-76405 Rev. * H - was 512 bytes.

Also, when recording 256 bytes of data (B.3.1), I do not get bit 2 (Socket 2 Available) of the PP_SOCK_STAT_L register (0x9E) is set (B.3.2.a). When recording 512 bytes bit 2 == 1 (ok).

According to B.3.2.d, read the PP_DMA_SIZE register (0x8F) and verify that the value is 0x0100. I am reading PP_DMA_SIZE == 0x0200.

I see Appendix B: Troubleshooting Steps for Sync ADMux Boot differs from Section 9.1.7 Firmware Download Example (Document No. 001-76405 Rev. * I).

Which of them is the right one to download the firmware in FX3 via the synchronous ADMux interface?

I performed the firmware download from a host processor to FX3 via the 16-bit synchronous ADMux interface as specified in the Firmware Download Example 9.1.7. But my firmware did not work.

What should I do extra what is not specified in Document No. 001-76405 Rev. * I

0 Likes
1 Solution
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

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 [3]) 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.

View solution in original post

6 Replies
KandlaguntaR_36
Moderator
Moderator
Moderator
25 solutions authored 10 solutions authored 5 solutions authored

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.

0 Likes
Anonymous
Not applicable

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?

0 Likes
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

The response data (0x57, 0x42, 0x00, 0x00) is fine.

The response[0] 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 [2] byte is don't care.

Please go ahead with testing the firmware download part (section B.4) and let us know the test result.

0 Likes
Anonymous
Not applicable

Hi.

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)?

0 Likes
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

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 [3]) 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.

Anonymous
Not applicable

I temporarily stopped working with ADMux.

0 Likes