- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Solved! Go to Solution.
- Tags:
- boot-up
- fx3
- gpif admux
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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()
- read back SOCK_STAT_L
- Write 0x300 to DMA_XFER
- read back DMA_READY_EV from PP_EVENT
- check DMA_XFER (reads back as 0xb300)
- write 040 to PP_CONFIG (this is from sck_bootloader_write())
- Wait on RD_MAILBOX2 - fails we never get 0x33 back - stays as 0 (this is from sck_bootloader_write())
- 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:
With one byte incorrect at the end (I can live with that for the purposes of this)
(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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Rashi
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.