Hi all,
I'm trying to use the AN75779 project as a baseline to set up my MT9P031 as a UVC camera.
Here's what I did:
Modify GPIF state machine: changed to 16 bit wide bus with one clock per pixel, changed LD_ADDR_COUNT and LD_DATA_COUNT limits to 8183 to account for this. Changed the active clock edge to falling.
In order to fake the YUY2 I tied data 15 high and 14:8 low so the upper byte would be 0x80. Then I just attached my most significant 8 bits of my camera bus to data lines 7:0.
Overhaul to the I2C in sensor.c code. The MT9M114 uses two bytes of register addresses in its protocol while the MT9P031 only has one so I had to get rid of the upper address byte in all the functions. I got rid of all of the configuration for MT9M114 and only wrote in commands to set my sensor up to run 720p at whatever rate it runs. I figured initially setting the sensor up to do 720p to match the existing project would be the path of least resistance.
I have a 24MHz clock and the datasheet suggests it would get 60fps with 96MHz so I assume it's actually going to give 15fps instead of 30.
In the UVC Descriptor C file, I've tried just leaving everything alone, as well as increasing the frame time to double or four times the original (so 0xA2C2A or 0x145854) to account for a lower FPS but nothing is helping.
The result is that Windows recognizes the device as a camera and I'm able to select it with the Windows camera app, and I see some response on the debug serial port when I do select or de-select it.
With the additional debug print enabled, I see "UVC: Completed (n) frames and 0 buffers."
Ultimately though I just get a black screen.
Do I need to use the PLL to increase my clock rate to actually achieve 30fps? Or do I need to adjust the minimum bitrate in the descriptor to reflect what the camera actually puts through?
Or am I missing something else?
Thanks in advance!
Show LessHi 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
Show Less
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
Hi,
I'm trying to debug my FX3 program with J-Link but after download finishes nothing happens. Debugger not didn't stop "main".
At the same time if I try to debug some SDK example program (e.g. UsbUART) it works fine.
Here is J-Link output for my program:
SEGGER J-Link GDB Server V6.96 GUI Version
JLinkARM.dll V6.96 (DLL compiled Feb 19 2021 09:55:51)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: on
Init regs on start: on
Silent mode: off
Single run mode: on
Target connection timeout: 5000 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: ARM9
Target interface: JTAG
Target interface speed: 1000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link EDU Mini V1 compiled Feb 18 2021 11:25:23
Hardware: V1.00
S/N: 801018450
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.30 V
Listening on TCP/IP port 2331
Connecting to target...
J-Link found 1 JTAG device, Total IRLen = 4
JTAG ID: 0x07926069 (ARM9)
Connected to target
Waiting for GDB connection...Connected to 127.0.0.1
Reading all registers
Read 4 bytes @ address 0x00000000 (Data = 0xE59FF028)
Received monitor command: speed 1000
Target interface speed set to 1000 kHz
Received monitor command: clrbp
Received monitor command: reset
Resetting target
Received monitor command: halt
Halting target CPU...
...Target halted (PC = 0x00000000)
Received monitor command: regs
PC = 00000000, CPSR = 000000D3 (SVC mode, ARM FIQ dis. IRQ dis.)
R0 = 00000000, R1 = 00000000, R2 = 00000000, R3 = 00000000
R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
USR: R8 =00000000, R9 =00000000, R10=00000000, R11 =00000000, R12 =00000000
R13=00000000, R14=00000000
FIQ: R8 =00000000, R9 =00000000, R10=00000000, R11 =00000000, R12 =00000000
R13=00000000, R14=00000000, SPSR=00000010
SVC: R13=00000000, R14=00000000, SPSR=00000010
ABT: R13=00000000, R14=00000000, SPSR=00000010
IRQ: R13=00000000, R14=00000000, SPSR=00000010
UND: R13=00000000, R14=00000000, SPSR=00000010
Reading all registers
Received monitor command: speed auto
Select auto target interface speed (2667 kHz)
Received monitor command: flash breakpoints 0
Flash breakpoints disabled
Downloading 9512 bytes @ address 0x00000100 - Verified OK
Downloading 16272 bytes @ address 0x40003000 - Verified OK
...
Downloading 16272 bytes @ address 0x40006F90 - Verified OK
Downloading 1688 bytes @ address 0x40030000 - Verified OK
Writing register (PC = 0x40014634)
Read 4 bytes @ address 0x40014634 (Data = 0xE59F1034)
Read 4 bytes @ address 0x00000000 (Data = 0xE59FF028)
Received monitor command: memU32 0xE0052000 = 0x00080014
Writing 0x00080014 @ address 0xE0052000
Received monitor command: sleep 1000
Sleep 1000ms
Reading all registers
Starting target CPU...
And debugger windows shows:
Looks like it really running because I see device is recognized in my windows device manager.
But for some reason in doesn't stop neither at main, nor at any other breakpoint.
I'll greatly appreciate any help here
Things I checked so far:
1) Disabled entering to suspend mode
2) Added CPU frequency change at startup as per KBA229087
Show Less
Hi,
I'm trying to use the watermarks to end the GPIF2 data transfers.
My FX3 design is a 32b slave FIFO with flagA as ready/empty and flagB as watermark (both thread dependent). When accessing the FX3 in RD mode (U2P), the watermark is working as expected and everything goes great.
When accessing in WR mode (P2U), for some reason, the watermark comes earlier than what I would expect. I'm sending a whole FX3 buffer (16KB) from my FPGA and counting the amount of data sent (in 32b words), so for now the watermark flag it is not at the FPGA side.
The watermark for P2U access is configured with a value of 6, so, according to the documentation, the flag should go down when there are 2 samples left to be sent. At the FPGA I'm double registering the watermark, so I'm expecting the watermark to become low when there is no more data to be sent. However I still see that, even after the 2 cycle delay, the watermark does not arrive where I am expecting it.
I'm including the chip scope capture so you can have a look, as well.
The configuration for the FX3 watermark is as follows:
Thanks in advance.
Show LessHi,
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:
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
Show LessHello,
I can't speak English well.
In the FX3 SlaveFIFOSync 5Bit example, we want to use 6 ENDPOINTs.
endpoints 0x1, 0x2, 0x3 works well.
But endpoints 0x81, 0x82, 0x83
BULK IN transfer
BULK IN transfer failed with Error Code:997 occurs.
I checked the 5bit FIFO ADDR
From 0 to 31, the flag of the INPUT endpoint did not occur.
Only output endpoint 0x1~0x3 operates.
If you change the positions of CY_U3P_PIB_SOCKET_0 and CY_U3P_PIB_SOCKET_4, this time they all change to INPUT and OUTPUT does not work.
Can you explain what the problem is?
I want to use all 6 ENDPOINTs
Thank you.
Show LessI have a question about Bulk Out transfer.
Currently I am using Bulk Out transfer to stream data into our logic.
The data to be sent is 0x80100 bytes for each Bulk Out transfer.
The source code of the application is shown below.
int MyXferBulkOut(unsigned char *dt, int length)
{
CCyUSBDevice *USBDevice;
CCyUSBEndPoint *OutEndpt;
bool success;
ULONG ret;
int instance;
USBDevice = s_USBDevice; // USB Device Object, when we are get on initialization.
OutEndpt = USBDevice->EndPointOf(0x02); // BulkOut EP2, Auto DMA, Buffer Count = 4
if (OutEndpt == NULL) {
return(-1);
}
OutEndpt->TimeOut = 5000;
success = OutEndpt->XferData( dt, length ); // length = 0x80100;
if (success) {
ret = 0;
}
else{
ret = -1;
}
return ret;
}
I have some problem.
After executing 0x80 100byte Bulk Out transfer with the XferData function in the above source code, immediately after the function returns
Bulk Out transfer the next 0x80 100byte data.
At this time, the length of data transmitted to our logic circuit is often shorter than expected.
The cause is completely from the EndPoint Buffer of EP2 to our logic circuit immediately after the XferData function returns.
Since it has not been flushed and the XferData function is called again in the above source code in that state,
This is because the previous data remains in the End Point Buffer of EP2 and the next Bulk Out transfer is instructed.
I'm guessing.
I have a few questions.
Q1. Is there any data left in the Endpoint Buffer immediately after the XferData function (BulkOut) returns?
Or does calling the XferData function transfer to EP2-> EP2's Buffer is completely flushed before returning?
Q2. If there is any data left in the EP2 Endpoint Buffer when the XferData function (BulkOut) returns, that is
How to check if it is empty?
Best regards.
Show LessWe use CYUSB3KIT-001 to connect to TypeC HUB and encounter FX3 streaming media transmission failure problem.
A few transfers were successfully transferred at first, and then the transfer continued to fail.
Once the transmission fails, the transmission cannot be continued.
The same problem occurs bulk in and bulk out.
But using USB storage for transfer is successful.
We want to ask:
1. The reason for the transmission failure?
2. Is there any way to solve this problem?
3. What is the difference between Streamer and Storage transmission?
Hi!
I have the following system: FPGA -> FX3(superSpeed explorer kit)->PC
I send counter from FPGA, but on pc i get shuffled data in multiples of packet size (1024)(1.png in attachments)
I try different parameters of DMA counts, DMA buffer size, but always the same
FX3 work on modified FIFO sync mode(from examples)
I'm not quite sure what other information to provide, so ask, I'll attach
Show LessEmployee
Employee
Employee