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

USB superspeed peripherals Forum Discussions

NTaub
Level 1
First like received First like given 5 replies posted
Level 1

I've been trying to implement a SPI interface on FX3 in order to reprogram a flash IC driving an FPGA, similar to the implementation described in AN84868 . I've been able to read from and write to the flash chip when I load slightly modified* versions of the USBFlashProg and UsbSpiDmaMode examples into RAM, but if I build the same code as an I2C image and load it onto the FX3's I2C boot EEPROM,  the FX3 crashes and returns nothing but code 997 as soon as I make a SPI request.

Things I've already tried:

1) All three available speeds, 64k and 128k I2C sizes in elf2img.exe's -i2cconf argument. Of the settings that could be successfully programmed to the I2C EEPROM, none of them had any discernible effect

2) Performing a SPI read operation while the SPI mux select pin* is pulled low; this doesn't cause a crash, but the data returned is all zeroes (for obvious reasons)

3) Changing the DMA timeout value from 0xFFFFFFFF to 0x00004000 -- no effect at all

4) Checking SPI busy status before performing a SPI read operation -- the check busy status command also crashed the FX3.

5) Using I2C in register mode instead of using DMA -- no effect

6) Commenting out all of the "if (status != CY_U3P_SUCCESS) {return status;}" statements -- no effect

7) disabling and reinitializing SPI and I2C before making any SPI requests -- no errors were returned during DeInit and Init calls for I2C and SPI, but the crash happened as soon as I made a SPI request

8 ) Commenting all I2C functions out and setting io_cfg.useI2C to CyFalse. 

I'm out of ideas. I can't think of any reason that booting from I2C should have any impact on SPI operation in a way that wouldn't be solved by one of the things I tried. Has anyone else encountered anything like this? 

 

* An external mux select needs to be pulled high to give the FX3 access to the SPI flash IC, but it's driven from a GPIO so I just use CyU3PSetSimpleConfig()  with .outValue set to CyTrue. 

 

 

EDIT: I was able to capture oscilloscope readings on the MOSI trace between the FX3 and the SPI flash. Here's a capture of a CY_FX_RQT_SPI_FLASH_ERASE_POLL when the image is loaded via RAM:

bootfromramcap.png

 

and here's the same command running the exact same image booting from I2C:

bootfromi2ccap.png

 

I've seen this happen on every command -- if the FX3 was booted from I2C, the MOSI line has a lower-voltage "echo" after each pulse.  Additionally, there is no activity at all on the MISO line after booting from I2C no matter what commands are sent. 

When a SPI read request is made after booting from I2C, the FX3 continually broadcasts the same pulse and echo until power is removed, suggesting that the crash is happening because the FX3 is stuck in a loop attempting to make contact with the SPI flash IC. However, setting a timeout in the SPI configuration settings does not fix this issue. 

0 Likes
8 Replies
Rashi_Vatsa
Moderator
Moderator 500 solutions authored 1000 replies posted 750 replies posted
Moderator

Hello,

From the description, I understand that the booting from I2C EEPROM is successful (the device enumerates as expected) but after booting the read/writes to SPI doesn't work.

Please let me know what changes are done in the .img  to make it I2C image. The image build using EzUSBSuite will have bImageCTL = 1C. Please let me know what is I2C EEPROM size you are using in your application.

Kindly, let me know if you program the I2C image in RAM, does it work?

Regards,
Rashi
0 Likes
NTaub
Level 1
First like received First like given 5 replies posted
Level 1

I'm using a Microchip AT24CM02 2Mb EEPROM; using the -i2cconf argument of elf2img.exe I've set the bImageCTL byte to 0x0C, 0x1C, and 0x2C (0x*E results in Control Center failing to program the EEPROM) without any noticeable effect. The stable image that we've been using is built without the -i2cconf argument and has worked reasonably well with the exception of SPI communication. 

If I program the exact same image into RAM from Control Center, the device is able to use all features (including both I2C and SPI) without issue. 

0 Likes
NTaub
Level 1
First like received First like given 5 replies posted
Level 1

@Rashi_Vatsa to clarify a bit further, the device boots and enumerates without issue when booting from I2C, it only stops working when a SPI data request is made. After a little bit more experimentation, I determined that even sending and reading data to/from the SPI EEPROM's control registers does not cause any issues, the problem only arises when attempting to read or write the contents of the flash memory.

 

I was able to capture the difference between a read command run after booting from USB vs booting from I2C:  

SPI_READ_RAM.png

SPI_READ_I2C.png

0 Likes
Rashi_Vatsa
Moderator
Moderator 500 solutions authored 1000 replies posted 750 replies posted
Moderator

Hello,

Please let me know if it is possible for you to share your firmware for us to check.

Also, kindly let me know if you can reproduce the issue with CYUSB3KIT-003

Regards,
Rashi
0 Likes
NTaub
Level 1
First like received First like given 5 replies posted
Level 1

I'm unable to share the firmware that I've been using due to confidentiality concerns, however I can share the following:

  1.  The same effect occurs when the "UsbSpiRegMode" or "UsbSpiDmaMode" sample firmware is loaded onto this device and run (with pin 45 pulled high to operate the mux select on the device, but no other modifications)
  2. This device includes an FPGA configured for 32-bit asynchronous FIFO communication with the FX3 acting as a slave device. However, these issues have occurred even when the FX3's FIFO communication is configured as 16-bit or even not initialized at all. 
  3. The same issue does not occur on a CYUSB3KIT, but I am currently unable to add a FIFO communication bus or working SPI EEPROM to the CYUSB3KIT.
  4. On both my device and the CYUSB3KIT, the I2C configuration registers will read different values depending on whether the FX3 is booted from RAM or I2C: specifically, when booted from I2C, register 0xE0000C00 will read 0x04000000, register 0xE0000404 reads 0x300000CF, 0xE0000C414 reads 0xFFFFFFFF, and  0xE0000C418 reads 0xFFFF0000,  but all of these registers all read as 0x0 when the FX3 is booted from RAM. 

 

0 Likes
Rashi_Vatsa
Moderator
Moderator 500 solutions authored 1000 replies posted 750 replies posted
Moderator

Hello,

Apologies for the delayed response.

The same issue does not occur on a CYUSB3KIT, but I am currently unable to add a FIFO communication bus or working SPI EEPROM to the CYUSB3KIT.

>> Please let me know if the SPI APIs work when the SPI slave is not connected to you FX3 board. Also, I understand that you have configured the GPIF of FX3 as 16 bits when you are using SPI block or when the GPIF state machine loaded?

On both my device and the CYUSB3KIT, the I2C configuration registers will read different values depending on whether the FX3 is booted from RAM or I2C

>> Please confirm if you are reading FX3's registers

Regards,
Rashi
0 Likes
NTaub
Level 1
First like received First like given 5 replies posted
Level 1

On the custom device, the intent is to switch to either a 16-bit or 24-bit synchronous slave FIFO mode when SPI is needed, but I have also experimented with completely disabling FIFO or even completely rewriting the I2C EEPROM with an image that contains no FIFO or GPIF configuration at all, and the same result occurs. 

When SPI is enabled on the custom device but the SPI EEPROM is blocked by a low mux signal, the SPI API works normally (although of course no data is received). 

I have read FX3 registers both using the CyU3PReadDeviceRegisters and and the built-in JTAG debug functionality of the Explorer Kit, and in both cases what I observed was that the I2C registers (starting at 0xE0000400) would be completely blank if the device was booted from USB, but populated if the device was booted from I2C EEPROM. Also, if the Explorer Kit was booted from I2C and CyU3PSendStopCondition() is not used, register 0xE0000434 ( I2C_CLOCK_LOW_COUNT) will constantly increment even when the Kit is held at a breakpoint by JTAG debug. 

0 Likes
Rashi_Vatsa
Moderator
Moderator 500 solutions authored 1000 replies posted 750 replies posted
Moderator

Hello,

To debug the issue further, please let me know which GPIO are you using for driving the mux.

Please help me with the below points:

- Please capture and share the traces when the SPI slave is not connected to FX3 and the I2C boot is done. Is the echo/lower voltage on MISO/MOSI seen?
- Can you please test the read/write to SPI slave without using mux? 
- Please let me know if there is any activity on SPI lines when the fx3 is booting up from I2C

Regards,
Rashi
0 Likes