Part Number: TDA4VH-Q1
(on PSDK 11.2)
I have been experimenting with csirx error handling.
For that, I sent a MIPI-CSI stream with large number of errors. The stream was coming from GMSL-connected camera, over max96717 serializer and max96714 deserializer, in tunneling mode. To inject errors, I used max96717 serializer error generator. I've configured it with register 0x2a set to 0x0 - that is, inject unlimited number of single bit errors, in average once per 5120 bits [of raw GMSL stream].
This erratic stream was sent to TDA4 CSIRX. CSIRX was configured with error bypass:
instCfg.enableErrbypass = UTRUE
While receiving the erratic stream, the csirx driver reports CSIRX_EVENT_TYPE_ERR_PAYLOAD_CRC and sometimes also CSIRX_EVENT_TYPE_ERR_FIFO_OVERFLOW_STRM0 error events.
After error generator in the serializer is disabled, csirx stops reporting error events. So receive looks like recovered.
However, sometimes (maybe in 50% of experiments) frames received by CSIRX after error generator disabled are written to buffers with offset of 8 bytes. And, the last 8 bytes of the frame end in the first 8 bytes of the next buffer.
Looks like heavy error rate causes the data path to somehow get out of sync?
This misbehavior reproduces only with a high error rate. With lower error rate, could not reproduce.
Looks like it is somehow connected to FIFO_OVERFLOW_STRM0 - when these are not reported, did not observe the misbehavior. However, also observed cases when FIFO_OVERFLOW_STRM0 was there but the misbehavior did not happen.
When FIFO_OVERFLOW_STRM0 happens, csirx driver currently tries to reset the stream. I guess that at this point need to also somehow flush and/or reset the PSIL DMA where data from stream0 is forwarded. However, I'm not that familiar with TDA4 hardware to implement this.
Any comments on this situation are appreciated.
For now looks like need to handle CSIRX_EVENT_TYPE_ERR_FIFO_OVERFLOW_STRM0 as a fatal error, after which further operation is not possible without full reset and restart...
