USB Superspeed Peripherals

Hi!

I'm looking for an example that streams parallel data back to a PC using the GPIF on an FX3. Does such an example exist? I'm attempting to build an SRAM sniffer.

Thanks!

Hi,
I used cyfxuartlpdmamode example and modified the channel to UART-> CPU ( MANUAL IN) and another channel CPU ->UART (MANUAL OUT). I attached my new firmware.  I used the UART event(UartIsr). I send data from Teraterm, I got ISR after sending 16-bytes(DMA size). I put a fixed buffer, when I got the ISR, I send that data to Teraterm. Up to here, everything is ok. But I have 2 problems:
1- I don't get another ISR. I mean I sent 16 bytes first time, I got letters A to Q (fixed buffer) in Teraterm, but again I entered another 16 bytes and I expected to get another ISR, but I don't get. I think the previous event hasn't had clear, and I don't know how I should do that.(SendDebugMessage(buf, len))

2- When I try to replace the fixed buffer with the input buffer, I got nothing. (SendDebugMessage(buf_p.buffer, len))

Could you please help me on this matter?

Thanks

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 All,

I am writing firmware for the CX3 to interface a new sensor and am running into a confounding problem.  My program behaves differently when I rearrange the order of functions in my C source code.  This leads me to believe I have some memory corruption issues.  I found the CyU3PMemCorruptionCheck() and CyU3PBufCorruptionCheck() functions in cyu3os.h and am trying to use them in my program.  But when I do, the linker complains they are not defined.  In what library are they defined?

Thanks,

Scott

Hi

I am developing a firmware that streams data  at 1080p@30 fps, I have  attached the parameters given I am not able to do streaming , the project is also attached , Is there any wrong configuration setting.

Thanks in Advance

Dear sir,

Now I am trying the develop a product with CYUSB3014, and I am reading 2 documents to help me understand it.

<<001-76074_EZ-USB_FX3_Technical_Reference_Manual.pdf>> and <<001-92220_AN75779_How_to_Implement_an_Image_Sensor_Interface_with_EZ-USB_FX3_in_a_USB_Video_Class_UVC_Framework.pdf>>

And I find a problem.

In the chapter 7.11 of Techincal reference manual, there is a flag named DMA_RDY_TH0. And DAM_RDY_TH1.

According to my understand, this flag is used to solve the GPIF's problem between data transfer and the DMA buffer switch in different thead. When the thread is swith to used a free DMA buffer, this flag is used to pause the data transfer.

So if the GPIF used 2 thread to receive the data, this flag should be used.

But in the AN75779, I did not find any information about this flag. So does it mean that there is a loss of data during the 2 thread switch in AN75779 example?

Thanks

Chad

 AMCAP application  unable to display any data on its screen.  On PC side we are able to see data through USB analyser but not on the AMCAP application.

Image sensor: AR1335
AR1335 configured with : RAW8 , 640*480 @ 2FPS and CSI clock-160MHz

CX3 MIPI Configurations :
INPUT video format :        RAW8
OUTPUT video format :    24bit
                                                   640*480 @ 6FPS and CSI clock-160

CyU3PMipicsiCfg_t:
CyU3PMipicsiDataFormat_t dataFormat :      CY_U3P_CSI_DF_YUV422_8_2 (also tried CY_U3P_CSI_DF_RGB888 , CY_U3P_CSI_DF_RGB565_2 )
hResolution =640

CyCx3USBSSConfigDscr:
Number of bits per pixel:            16 (8 bit also tried )
Width in pixel:                                 320 (640 also tried)
0x59, 0x55, 0x59, 0x32,              /*MEDIASUBTYPE_YUY2 GUID: 32595559-0000-0010-8000-00AA00389B71 */
0x00,0x00,0xe1,0x00,            Min bit rate (bits/s):14745600=640*480*8*6
0x00,0x00,0xe1,0x00,            Max bit rate (bits/s):14745600=640*480*8*6
0x00,0xb0,0x04,0x00,           Maximum video or still frame size in bytes(Deprecated)  640*380

CX3- log :
TimeDiff = 10686 ms FPS = 2
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 31 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 32 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 33 Frm_Sz = 691200 B
Prod = 18 Cons = 18 Prtl_Sz = 28512 Frm_Cnt = 34 Frm_Sz = 691200 B

With Regards
channabasappa

Parameter "int errno" on line 74 of main.cpp conflicts with typical C++ usage resulting in compilation errors. 

Changing "errno" to "errnum" and adjusting the remainder of "libusb_error" to use "errnum" fixes the build problem.   After the suggested change, cyusb_linux build and runs.

Modified source code for "libusb_error" is attached.

After successfully complied the project, EZ USB suite generates .img and .elf files inside the project directory. Is it possible to configure the tool so it can generate .bin file that can be used in a universal chip programmer?

Tony

I'm feeling a little out of my depth here as I'm a System Administrator rather than a seasoned Electronics Engineer, I hope this question makes sense...

I am trying to upgrade two machines, that each have several Cypress Westbrige devices attached to them, from Ubuntu 16.04 to Ubuntu 20.04. With Ubuntu 16.04, all devices enumerate correctly first as 04b4:00f3 and then go on to download their custom firmware, detach and reattach. However, with 20.04 I get the following errors:

Feb 23 12:05:47 master kernel: usb 1-6-port1: status 0101, change 0000, 12 Mb/s
Feb 23 12:05:47 master kernel: usb 1-6-port1: indicator auto status 0
Feb 23 12:05:47 master kernel: usb 1-6.1: new full-speed USB device number 3 using xhci_hcd
Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32
Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32
Feb 23 12:05:47 master kernel: usb 1-6.1: new full-speed USB device number 4 using xhci_hcd
Feb 23 12:05:47 master kernel: usb 1-6.1: device descriptor read/64, error -32
Feb 23 12:05:48 master kernel: usb 1-6.1: device descriptor read/64, error -32
Feb 23 12:05:48 master kernel: usb 1-6-port1: attempt power cycle
Feb 23 12:05:48 master kernel: usb 1-6-port1: not enabled, trying reset again...
Feb 23 12:05:48 master kernel: usb 1-6.1: new full-speed USB device number 5 using xhci_hcd
Feb 23 12:05:48 master kernel: usb 1-6.1: Device not responding to setup address.
Feb 23 12:05:48 master kernel: usb 1-6.1: Device not responding to setup address.
Feb 23 12:05:49 master kernel: usb 1-6.1: device not accepting address 5, error -71
Feb 23 12:05:49 master kernel: usb 1-6.1: new full-speed USB device number 6 using xhci_hcd
Feb 23 12:05:49 master kernel: usb 1-6.1: Device not responding to setup address.
Feb 23 12:05:49 master kernel: usb 1-6.1: Device not responding to setup address.
Feb 23 12:05:49 master kernel: usb 1-6.1: device not accepting address 6, error -71
Feb 23 12:05:49 master kernel: usb 1-6-port1: unable to enumerate USB device

Two other similar devices connected to this machine at 1-6.3 and 1-6.4 show identical errors.

I have tried:

• using 'uhubctl' to power cycle the ports of the 1-6 hub
• using 'uhubctl' to reset each of the ports on the hub
• adding the 'usbcore.autosuspend=-1' kernel parameter (after reading your KBA222372 - Trouble Shooting Guide for the FX3/FX3S/CX3 Enumeration)
• adding extra time for the device descriptor read with kernel parameter 'usbcore.initial_descriptor_timeout=10000' (10s rather than the default 5s)
• setting various combinations of 'usbcore.use_both_schemes' and 'usbcore.old_scheme_first' to change method the kernel uses to initialise USB device

Have any other users experienced similar problems Cypress FX3 based devices when running Ubuntu 20.04?

Thx