At such high fps, there might be issues. Prior testing is needed before coming into conclusions.
thanks for your quick response. I tried to configure the MIPI Receiver Configuration tool with my settings but there seems to be an issue with the FIFO delay time. Setting the CSI clock to 170 MHz causes a Min/Max value of 0 to +3.26 us.
Raising to 200 Mhz leads to the error message "ERROR: Suitable FIFO delay value cannot be found" and Min/Max values are 0 to -5.32 us.
After saving this and loading again, this error is cleared and the config just looks fine.
Could this be a bug in the software? I'm going to run this config on our device and see what happens on the MIPI receiver.
1)CX3 cannot support 7200fps. This is mainly limited by the GPIF II interface in CX3. The minimum vertical blanking that we can support is 200uS with the latest CX3 state machine and 500uS with the CX3 state machine available as part of FX3 SDK 1.3.3.
2) It looks like you are using older CX3 MIPI configuration tool. We have updated the CX3 tool and it can be downloaded from the following link:
Please download and install Update to CX3 Configuration Eclipse Plug-ins.zip
file from the same. A document is present in the zip file which explains the update procedure.
I downloaded the Eclipse update and installed it. Thank you.
Our current configuration might not work for the whole CX3, but for the MIPI receiver I would expect that there are no errors. But during testing I read the error counts structure every second (first parameter True) using the MIPI error thread and I get the following output:
Framing Error Count = 0x0
CRC Error Count = 0x8
Multi-Data Lane Sync Byte Error Count = 0xFF
Control Error (Incorrect Line State Sequence) Count = 0x0
Unsupported Packet ID Error Count = 0x57
Recoverable Packet Header Error Count = 0x5F
Unrecoverable Packet Header Error Count = 0xFF
Recoverable Sync Byte Error Count = 0xFF
Unrecoverable Sync Byte Error Count = 0xB
CRC, Unsupported Packet ID and Recoverable Packet Header are counted up continuously, while the other errors stay the same, at 0xFF.
The configuration I used was:
What's the reason for this?
CRC error counter is incremented when a HS packet is received with crc errors.
Recoverable Packet Header Error Counter is incremented when a HS packet header is received with errors that are correctable by ECC.
Un-supported Packet ID Error Counter is incremented when a HS packet that is not supported by CSI-2 Rx is received.
Please check if the image sensor is configured correctly.
Also please note that the error counters does not wrap around and retains the maximum value until cleared by software. That is the reason why you are seeing the error count as 0xFF.
thanks for the explanation. If there are errors at the MIPI receiver, will the transmission of data be cancelled? Or will the MIPI receiver just keep going? It seems not. I would rather expect that the state machine will be halted at the GPIFII because of lack of valid line valid or frame valid data. But that shouldn't effect the DMA to USB endpoint transfers, right?
The VSYNC and HSYNC may not toggle as expected if there are some errors on the MIPI side.
As you mentioned the state machine may get stuck in some states(because transition condition will not be met). If VSYNC and HSYNC are not toggling the data will not be sampled and you will see a blank screen at the host side.