USB superspeed peripherals Forum Discussions

Hello

Please tell me about the pin status of G7 (FLAGA).

Target parts: CYUSB3014-BZXI (FX3)
FX3 mode: SlaveFIFO
Target pin: G7 (FLAGA)
Phenomenon: After the power is turned on, the G7 output is undefined when the USB is not connected.

Assumption: Only the power is applied to the FX3 implementing board without connecting the USB cable.

Q1)  Please tell me the output specifications of FLAGA after the power is turned on and there is no USB connection.

Q2) After turning on the power, can the output of FLAGA become indefinite (Hi-z, etc)?
If so, what are the possible causes?

Q3)  As a workaround  for "Q2" above, is it possible to improvement the FLAGA output from becoming indefinite by changing the firmware of FX3 without changing the H/W?

Best regards

Arai

Hi there,

We are seeing an issue with our design that is very similar to

Solved: CYUSB3014 freezes during Slave FIFO transfer - Infineon Developer Community

Solved: Re: How to debug device stall - Infineon Developer Community

Solved: FX3 Superspeed communication fails on link errors - Infineon Developer Community

however none of the above provides a definite answer.

Let me outline the test design, that is basically your slave FIFO example: we have an FPGA interfacing with the controller, and that FPGA pushes 4096x32 bits into the controller whenever a DMA buffer becomes available (both FLAGA and FLAGB high). The USB controller FW only has an additional IIC block, otherwise identical to the example files. Attached the modified .h and .c files. On the PC side we try to do continuous bulk IN transfers either with our c# software or your Streamer app.

What we see is the following:

In most cases (4 out of 5 or so) there are no issues and transfer progresses continuously at the expected 380 MBps or similar speed, for extended periods of time (tens of minutes).

In other cases the controller seems to initialize in a "strange" state. Not sure whether this is Windows10 or driver or FW or electronics issue, but the above bulk IN transfer fails after a few seconds or tens of seconds, stalling/freezing the controller. Soft reset temporarily resolves the issue and data transfer continues, but to fail again and again after short periods of time. What I found to resolve the problem is a hard reset of the controller (either pin C5 or CyU3PDeviceReset(CyFalse);) followed by a reprogram.

My questions:

1. Could you please advise on what causes this issue and how to solve it without having to hard reset?

2. Am I right saying that reset via pin C5 and CyU3PDeviceReset(CyFalse); are *exactly* the same or are there any differences between these?

Many thanks in advance,

Gergely

Cypress Semiconductor (now Infineon Technologies) used to publish USB product roadmap. As per the last roadmap published in early 2021,  FX3G2 was added as in development phase. But there is no information on its release. The product roadmap is not available on website now. Please help us in providing the latest USB product roadmap. Also, please let us know if there is any update on release of FX3G2 or other controllers such FX3G2D and RX4 etc.

Thanks & Regards,

Sunny Watts

Hello.

I had the inf file set up such that it runs a script that loads an image from a certain directory onto my FX3 chip as described in CyUSB.pdf. That worked fine for a while, but I've recently built a new image that registers another endpoint. I replaced the image at that path with the new one, but the FX3 still enumerates with the old number of endpoints, which tells me that we're still running old firmware.

I built the script using the record feature in the control center.

Why and how is the script loading an image that I've deleted and replaced, and how can I make it load the proper one? 

Thinking about it some more, I was assuming that the script loads the image based on it's path, but if it builds the image into the script instead of loading when the script executes, that would explain the discrepancy. Is that more accurate?

Hello.

I am using FX3 board for my development work and I flash the image to board via USB boot so far. I need to flash the firmware each time when I power ON the board. 
What about if I use I2C EEPROM/SPI Flash? Is it possible to permanently store the firmware so that I no need to flash it on each power cycle? and later, possible to erase it ?

please suggest, how can I implement it?

Thanks,

Best Regards.

Hello,

In order not to have to pass again the MS certification (WHQL), I would like to use the Cypress Driver Resell procedure for our USB device using an FX3 component (CyUSB3 driver + CyAPI lib)

According to the CyUSB.pdf document (p.15), I will add to the CyUSB3.inf file a new VID/PID couple for our device.

However, the access to our device must be exclusive. So I would also like to add the following line to the INF file:

cyusb3.inf:

...

[CYUSB3.AddReg.Guid]
HKR,,DriverGUID,,%CYUSB3.GUID%
; => add exclusive access here:
HKR,,Exclusive,0x10001,1

...

Is this possible without having to retake the entire Microsoft certification?

Best Regards

Hi,

I try to use JTAG to do on-line update of FX3 firmware (to ram directly).

For this, I have working implementations, both with custom and with OpenOCD.

Both implementations are doing the same thing: stop ARM926, reboot the System (to get to a known state), load binary to relevant places, set firmware entry point in memory at 0x40000000, trigger a reboot to get OTP rom code do platform initialization and jump back to the firmware.

Both implementations run fine, most of the time. But sometimes, it happens that FX3 gets unresponsive, both from USB (not enumerated) and from JTAG (does not react to TLR and chain discovery).

For instance, this happens when running OpenOCD with the following script in a loop:

source [find mem_helper.tcl]
source [find interface/ftdi/digilent_jtag_hs3.cfg]

reset_config trst_only

adapter speed 5000

jtag newtap fx3 cpu -irlen 4 -ircapture 0x1 -irmask 0xf -expected-id 0x07926069

target create fx3.cpu arm926ejs -endian little -chain-position fx3.cpu
fx3.cpu configure -work-area-phys 0x4003f000 -work-area-size 0x1000 -event "reset-assert" { }

init

arm7_9 dcc_downloads enable
arm7_9 fast_memory_access enable

echo "Halting target"
halt
soft_reset_halt

echo "Putting target in SVC mode"
reg cpsr 0xd3

echo "Enabling TCMs"
arm mcr 15 0 9 1 1 0x00000015
arm mcr 15 0 9 1 0 0xf0000019

echo "Setting oscillator parameters"
mww 0xE0052000 0x00080015

echo "Masking IRQs"
mww 0xfffff014 0xffffffff

echo "Loading firmware"
mww 0x40000000 0x00000000 3072
load_image firmware.elf 0 elf

echo "Jumping back to ROM, entry=0x40012b28"
# Firmware entry point, for boot rom
mww 0x40000000 0x40012b28

# Shell code that basically triggers a reset through GCTL_CONTROL
mww 0x40000004 0xe59f0018
mww 0x40000008 0xe5901000
mww 0x4000000c 0xe59f2014
mww 0x40000010 0xe1c11002
mww 0x40000014 0xe59f2010
mww 0x40000018 0xe1811002
mww 0x4000001c 0xe5801000
mww 0x40000020 0xeafffffd
mww 0x40000024 0xe0050000
mww 0x40000028 0x40000007
mww 0x4000002c 0x20000001
reg pc 0x40000004
resume

irscan fx3.cpu 4
runtest 10

shutdown

After some successful iterations giving out:

Open On-Chip Debugger 0.10.0+dev-01411-g051e80812-dirty (2020-09-30-16:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 5000 kHz
Info : JTAG tap: fx3.cpu tap/device found: 0x07926069 (mfg: 0x034 (Cypress), part: 0x7926, ver: 0x0)
Info : Embedded ICE version 6
Info : fx3.cpu: hardware has 2 breakpoint/watchpoint units
Info : starting gdb server for fx3.cpu on 3333
Info : Listening on port 3333 for gdb connections
Halting target
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000013 pc: 0x40012cf0
MMU: enabled, D-Cache: enabled, I-Cache: enabled
requesting target halt and executing a soft reset
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x600000d3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Putting target in SVC mode
Enabling TCMs
Setting oscillator parameters
Masking IRQs
Loading firmware
Jumping back to ROM, entry=0x40012b28
shutdown command invoked

 I get to a point where chain enumeration is broken (basically, FX3 does not drive TDO any more):

Open On-Chip Debugger 0.10.0+dev-01411-g051e80812-dirty (2020-09-30-16:01)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 5000 kHz
Info : JTAG tap: fx3.cpu tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Warn : JTAG tap: fx3.cpu UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 0xffff, ver: 0xf)
Error: JTAG tap: fx3.cpu expected 1 of 1: 0x07926069 (mfg: 0x034 (Cypress), part: 0x7926, ver: 0x0)
Error: Trying to use configured scan chain anyway...
Error: fx3.cpu: IR capture error; saw 0x0f not 0x01
Warn : Bypassing JTAG setup events due to errors
Info : Embedded ICE version 15
Error: unknown EmbeddedICE version (comms ctrl: 0xffffffff)
Info : fx3.cpu: hardware has 2 breakpoint/watchpoint units
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Info : starting gdb server for fx3.cpu on 3333
Info : Listening on port 3333 for gdb connections
Halting target
requesting target halt and executing a soft reset
Error: Jazelle state handling is BROKEN!
target halted in Jazelle state due to debug-request, current mode: Supervisor
cpsr: 0xffffffd3 pc: 0x00000000
MMU: disabled, D-Cache: disabled, I-Cache: disabled
Putting target in SVC mode
Enabling TCMs
Setting oscillator parameters
Masking IRQs
Loading firmware
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Warn : WARNING: unknown debug reason: 0xf
Warn : ThumbEE -- incomplete support
Error: timed out while waiting for target debug-running
Jumping back to ROM, entry=0x40012b28
Error: unhandled core state

The only thing that gets it back to a functional state is to cycle power. Sometimes, toggling reset pin also gets it out of limbo, but not always. I cannot rely on reset pin.

Now the questions:

1. Is this a known defect ?
2. Supposedly, JTAG should have precedence on reset pin, not the other way around, is this a known issue ?
3. Is there a known sequence that is known to produce stable results, i.e. something that can be run in a loop without getting to an unrecoverable state at some point ?

I could not find reference of 1. in public documentation or errata, I could not find reference code for 3.

As an illustration of 2., FX3 JTAG TAP does not answer when reset pin (not trst) is asserted, while TAP should still answer in such cases.

Thanks

Hi,

We have an application with custom sensor based on AN75779. We have tested multiple resolutions (720p, 1080p and VGA) - everything is working as expected. 

For the project we must support ROI (or sort of ROI). What we need is possibility to change sensor resolution via UVC extension unit (that is not an issue, there are guides on this). From sensor perspective this is easy to accomplish, only few registers must be changed. Our issue is with FX3 itself. How can we support this on descriptor side ? At the moment, in our descriptor, we have 2 frame descriptors defined. This only allow our device to work with these 2 resolutions. Can this be changed during runtime ? I am thinking about something like this:

1. Receive UVC extension command from host indicating a desired window (ex. 320x240)

2. Stop sensor streaming and adjust it's registers to support desired window

3. Update descriptor ?? so that host application can now read this 320x240 windows via opencv.

Basically we need FX3 to transmit any resolution that is set, and is possible to achieve by means of bit rate.

I do have additional question, but I do not want to create additional case for this:

4. In the future, for the best user experience, we would like our final product to only work with our custom APP. We do not want our camera to work with VirtualDub etc. What can be done to achieve such scenario? We have been thinking about a simple handshake between camera and host application, but it does not seem to be a go to solution. Can a simple descriptor change do the trick ? We need the device to be visible as camera within system, so that opencv can be used to retrieve data from it.

Thanks in advance for any assistance.

BR