FX3 ADMux boot mode questions

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

cross mob
GrWh_4681056
Level 2
Level 2
Welcome!

in AN76405 chapter 9 we have

/* Check PP_CONFIG register and make sure FX3 device is configured */
/* When FX3 bootloader is up with correct PMODE, bootloader configures */
/* the GPIF II into proper interface and sets the CFGMODE bit on PP_CONFIG
*/
val = IORD_REG16(PP_CONFIG);
if ((val & CFGMODE)== 0) {
  printf("ERROR: WB Device CFGMODE not set !!! PP_CONFIG=0x%x\n", val);
  return FAIL;
}

If I understand the comment correctly that is saying if be boot in SYNC ADmux PMODE[2:0] == Z 0 0, deassert reset we should find the masked bootloader has set up the GPIF and left us with CFGMODE set.  In the TRM Spec No.: 001-76074 Rev. *E we see the defintion of CFGMODE

This bit is cleared to “0” by firmware, by writing 0 to PIB_CONFIG.PP_CFGMODE, after completing

the initialization process. Specific usage of this bit is described in the software architecture. This bit is

mirrored directly by hardware in PIB_CONFIG.

I take that to mean that depending on the boot software (selected by PMODE) it may or may not be set.  Is this true?

However we find reading back at boot we get PP_CONFIG=0x000F.

Now by comparison Appendix B of AN76405 starts with

3. Write 0x0000 to the PP_INIT register at the address (FX3 address = 0x81).

4. Write 0x0040 to the PP_CONFIG register at the address (FX3 address = 0x82).

That appears to smash the hard-reset, then force the setting of CFGMODE. This might make sense for troubleshooting - but is it appropriate for normal boot? Certainly PP_INIT to reset is superfluous - I just pulled the hardware reset line.

I'm concerned that really the device is not coming up in the expected state, suggesting hardware or similar issues.

0 Likes
1 Solution

To close the loop for the original question:

If I understand the comment correctly that is saying if be boot in SYNC ADmux PMODE[2:0] == Z 0 0, deassert reset we should find the masked bootloader has set up the GPIF and left us with CFGMODE set.  In the TRM Spec No.: 001-76074 Rev. *E we see the defintion of CFGMODE

This bit is cleared to “0” by firmware, by writing 0 to PIB_CONFIG.PP_CFGMODE, after completing

the initialization process. Specific usage of this bit is described in the software architecture. This bit is

mirrored directly by hardware in PIB_CONFIG.

I take that to mean that depending on the boot software (selected by PMODE) it may or may not be set.  Is this true?

Cypress has confirmed

CFGMODE bit check is used for handshake and can be set manually (or ignored) during the firmware download process.

So the lack of CFGMODE may be expected, and doesn't indicate misconfiguration.

I hope that helps someone out there.

View solution in original post

0 Likes
8 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

If I understand the comment correctly that is saying if be boot in SYNC ADmux PMODE[2:0] == Z 0 0, deassert reset we should find the masked bootloader has set up the GPIF and left us with CFGMODE set. 

>> Yes, this understanding is correct

I take that to mean that depending on the boot software (selected by PMODE) it may or may not be set.  Is this true?

>> The default value of CFGMODE is 1 as shown 10.8.3 of the FX3 TRM which means on releasing the reset the CFGMODE should be 1 when the PMODE lines are configured for Sync Admux Boot

As mentioned in the application note AN76405 "On power-up or a hard reset on the RESET# line, the bootloader will take some time to configure GPIF II for the sync ADMux interface. This process can take a few hundred microseconds. Read/write access to FX3 should be performed only after the bootloader has completed the configuration. Otherwise, data corruption can result."

To avoid it, use one of the following steps:

1) Wait for 1 ms after RESET# deassertion.

2) Keep polling the PP_IDENTIFY register until the value 0x81 is read back. 

3) Wait for the INT# signal to assert, and then read the RD_MAILBOX registers and verify that the value readback equals 0x42575943 (that is, ‘CYWB’)

Please let me know if these steps are done and let me know the results

However, we find reading back at boot we get PP_CONFIG=0x000F.

>> Please let me know when if the status of PP_CONFIG read. Please try reading the PP_CONFIG register after the above steps are completed.

That appears to smash the hard-reset, then force the setting of CFGMODE. This might make sense for troubleshooting - but is it appropriate for a normal boot? Certainly, PP_INIT to reset is superfluous - I just pulled the hardware reset line.

>> The steps mentioned in Appendix B can also be used in the case where the user communicates with GPIF using  PP mode not necessarily for booting. In such a case, it is good to write 0x0400 to PP_CONFIG.

Regards,

Rashi

Regards,
Rashi
0 Likes

I take that to mean that depending on the boot software (selected by PMODE) it may or may not be set.  Is this true?

>> The default value of CFGMODE is 1 as shown 10.8.3 of the FX3 TRM which means on releasing the reset the CFGMODE should be 1 when the PMODE lines are configured for Sync Admux Boot

I don't see CFGMODE come up - see below

As mentioned in the application note AN76405 "On power-up or a hard reset on the RESET# line, the bootloader will take some time to configure GPIF II for the sync ADMux interface. This process can take a few hundred microseconds. Read/write access to FX3 should be performed only after the bootloader has completed the configuration. Otherwise, data corruption can result."

To avoid it, use one of the following steps:

1) Wait for 1 ms after RESET# deassertion.

2) Keep polling the PP_IDENTIFY register until the value 0x81 is read back. 

3) Wait for the INT# signal to assert, and then read the RD_MAILBOX registers and verify that the value readback equals 0x42575943 (that is, ‘CYWB’)

Please let me know if these steps are done and let me know the results

I use method "2", reading the PP_IDENTIFY unti it returns 0x81. That said, I have never seen it fail to return 0x81.  For safety I've also added plenty of delay after reset to be certain.

However, we find reading back at boot we get PP_CONFIG=0x000F.

>> Please let me know when if the status of PP_CONFIG read. Please try reading the PP_CONFIG register after the above steps are completed.

After method 1 and 2 I only see 0x000F

0 Likes

Hello Greg,

Please confirm if these steps are done after configuring the PMODE[2:0] as Z00.

If yes, please let me know if your board has the provision to configure the FX3 in USB boot (PMODE[2:0] = Z11). The reason for this is that we can boot FX3 (through USB) with sync admux application firmware and test if the data read by the PIB block is correct after following steps mentioned in Appendix B of AN76405 app note.

Regards,

Rashi

Regards,
Rashi
0 Likes

Please confirm if these steps are done after configuring the PMODE[2:0] as Z00.

Yes - we have a PMODE[2] disconnected and PMODE[1:0] tied together. they can be driven high for USB boot (all our prior testing has used this), and now driven low for GPIF boot.

If yes, please let me know if your board has the provision to configure the FX3 in USB boot (PMODE[2:0] = Z11). The reason for this is that we can boot FX3 (through USB) with sync admux application firmware and test if the data read by the PIB block is correct after following steps mentioned in Appendix B of AN76405 app note.

Fantastic idea - I don't see any admux examples other than the eMMC example for the FX3S?  Am I missing something?

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Greg,

I have modified the gpiftousb firmware of the SDK using the sync Admux state machine. Please enable the USB boot (Z11) and program the attached firmware to FX3.

The DMA channel is created between PIB socket 0 and USB socket 1 (USB OUT endpoint 1: 0x81). Please follow the steps mentioned in Appendix B ( till B.3.1 i.e. writing 512 bytes of data to FIFO/socket0). Once 512 bytes are written to socket 0, open the control center application and do a TRANSFER IN  on endpoint 0x81 and check if the data read by FX3 is the same.

I have also enabled debug prints to track the DMA buffers through Producer and Consumer events. Please check the UART debug prints while transferring the 512 bytes

Please let me know if this works

Regards,

Rashi

Regards,
Rashi

The DMA channel is created between PIB socket 0 and USB socket 1 (USB OUT endpoint 1: 0x81).

I assume you mean IN for 081, OUT for 01:

pastedImage_1.png

Please follow the steps mentioned in Appendix B ( till B.3.1 i.e. writing 512 bytes of data to FIFO/socket0).

I assume I skip B1.3 (PP_INIT -> reset) or I lose the programming.

B.1

  • I read back 0x81 from PP_IDENTIFY
  • I read back 0xc01 from PP_INIT (I skip writing to it)
  • I read back 0xf from PP_CONFIG

B.2

  • No issues here - reading/writing tests against these registers are fine

B.3

we proceed through sck_bootloader_write()

  1. read back SOCK_STAT_L
  2. Write 0x300 to DMA_XFER
  3. read back DMA_READY_EV from PP_EVENT
  4. check DMA_XFER (reads back as 0xb300)
  5. write 040 to PP_CONFIG (this is from sck_bootloader_write())
  6. Wait on RD_MAILBOX2 - fails we never get 0x33 back - stays as 0 (this is from sck_bootloader_write())
  7. Skipping step 5,6 and just setting PP_CONFIG to 0x40 at step B1 we proceed through the transaction.

The data is more or less received back over USB:
pastedImage_2.png

With one byte incorrect at the end (I can live with that for the purposes of this)

pastedImage_3.png

(Sorry cyusb_linux window doesn't expand, so I can't show more than 8ish lines of data).  The last byte should be 0xff.

debug initialized

USB event: 11 0

About to connect to USB host

USB event: 0 1

CY_U3P_USB_EVENT_CONNECT detected

CyFxApplnInit complete

USB event: 4 1

USB event: 5 1

USB event: 8 0

USB event: 8 0

Buffers Received : 0, Buffers Transferred: 0, GPIF_SMSTATE = 1

... repeats excluded

Buffers Received : 1, Buffers Transferred: 0, GPIF_SMSTATE = 1

... repeats excluded

Buffers Received : 1, Buffers Transferred: 1, GPIF_SMSTATE = 1

... repeats excluded

The data looks more or less correct except that last byte - that may well be in the USB code.

This matches my observations in the other thread that the read-back data shows the full transaction occurs, just half the data is missing on read-back.

0 Likes
lock attach
Attachments are accessible only for community members.

Hello Greg,

The DMA channel is created between PIB socket 0 and USB socket 1 (USB OUT endpoint 1: 0x81).

>> Pardon me. I meant to check the data on  IN endpoint

Writing data to FX3 seems fine except for the last byte. we would need the interface signal traces when the last byte is sent to FX3 for debugging it.

Meanwhile, we need to check if the reading of data is proper, this can be done by sending 512 bytes of data from the control center application on the OUT endpoint and Read the data from Socket 2 of the PIB interface as mentioned in step 4 of B3. The modified firmware is attached below.

Note: Please follow the complete steps from B1 to B3. As we are only checking read transfers, B3.4 can be implemented in B3 directly as B3.3 is the read command to the bootloader.

Please let me know if the data sent from USB (through control center) is the same as that received on Socket 2 of the PIB interface

Regards,

Rashi

Regards,
Rashi
0 Likes

To close the loop for the original question:

If I understand the comment correctly that is saying if be boot in SYNC ADmux PMODE[2:0] == Z 0 0, deassert reset we should find the masked bootloader has set up the GPIF and left us with CFGMODE set.  In the TRM Spec No.: 001-76074 Rev. *E we see the defintion of CFGMODE

This bit is cleared to “0” by firmware, by writing 0 to PIB_CONFIG.PP_CFGMODE, after completing

the initialization process. Specific usage of this bit is described in the software architecture. This bit is

mirrored directly by hardware in PIB_CONFIG.

I take that to mean that depending on the boot software (selected by PMODE) it may or may not be set.  Is this true?

Cypress has confirmed

CFGMODE bit check is used for handshake and can be set manually (or ignored) during the firmware download process.

So the lack of CFGMODE may be expected, and doesn't indicate misconfiguration.

I hope that helps someone out there.

0 Likes