Unpredictable behavior on custom board with DM385

Eli,

There could be multiple reasons why bootproc is exiting. From your boot log it also seems that there could be some problem with the sensor capture itself.

Is it possible that on your new board i2c is giving some trouble and sometimes sensor itself is not streaming?

Regards

Rajat

Hi Rajat,

I've attached a signal analyzer to the I2C clock and data channels, as well as HSYNC and VSYNC coming from the sensor.

It seems that the sensor startup configuration script is running properly and the register addresses and values are visible over the I2C channels.

After the registers are set, I can see valid HSYNC and VSYNC pulses, indicating data streaming, but still I get the bootproc timeout error.

Are there any other possible causes for this error?

You mentioned that from the boot log, it might be a problem with sensor capture. Could you please specify what line you're referring to?

Thanks,

Eli

I've tried running the board with a different sensor, AR0331, which is supported in the IPNC RDK.

It seems to run well and does not cause problems with FVID2_Control()

This is strange, since my custom sensor works well with the APPRO EVM and causes problems only with the custom board.

I've disabled all custom pin muxes and gpio settings but that didn't seem to help.

Are there any other places where I can take a look to find the root of the problem?

I've managed to solve the problem.

I've lowered the master clock of the sensor, and subsequently, the pixel clock signal which is sent to the camera connector.

Lowering it from 144MHz to 80MHz solves the problem.

Any possible reason this would cause problems on the custom board but not on the EVM?

Eli,

The parallel port supports 144 Mhz as well. SO I don't think maximum clock is the problem.

However, there could be other variables that may be affecting the capture on the interface, for example clock jitter or noise on the sync signals. If the jitter or noise is higher, at higher MHz the capture becomes less reliable. Lowering the MHz will add more timing margin and allow the capture to succeed.

But the above described is just one theory. If you are interested you can attempt debug by oscilloscope and also checking the SYNC registers and check as you increase clock if the VP can still capture.

Regards

Rajat 

Hi Rajat,

Could you provide more details about the SYNC registers you're referring to?

A little update:

I've done two things to try to solve the problem.

1) DDR3 wordwise software leveling

2) Increasing the value of the termination resistor on the sensor connector

None of those helped. However, I've noticed that slightly increasing the pixel clock to 115.2 MHz results in the following error shortly after boot-up, although video streaming works for a few seconds before it happen:

[m3vpss ] Unhandled Exception:
[m3vpss ] Exception occurred in ThreadType_SWI
[m3vpss ] handle: 0x8e513844.
[m3vpss ] stack base: 0x8ef44a90.
[m3vpss ] stack size: 0xa000.
[m3vpss ] R0 = 0x03bc03d0 R8 = 0x8ef3b00c
[m3vpss ] R1 = 0x00000010 R9 = 0x8ddf4938
[m3vpss ] R2 = 0x00000000 R10 = 0x8ddf4e3c
[m3vpss ] R3 = 0x00000000 R11 = 0x00000090
[m3vpss ] R4 = 0xbe903c80 R12 = 0x00000000
[m3vpss ] R5 = 0x00000090 SP(R13) = 0x8ef4e970
[m3vpss ] R6 = 0x00000090 LR(R14) = 0x8dddf57b
[m3vpss ] R7 = 0x03bc03bc PC(R15) = 0x8dd7ae94
[m3vpss ] PSR = 0x01000000
[m3vpss ] ICSR = 0x00400803
[m3vpss ] MMFSR = 0x00
[m3vpss ] BFSR = 0x82
[m3vpss ] UFSR = 0x0000
[m3vpss ] HFSR = 0x40000000
[m3vpss ] DFSR = 0x00000000
[m3vpss ] MMAR = 0x03bc03d4
[m3vpss ] BFAR = 0x03bc03d4
[m3vpss ] AFSR = 0x00000000
[m3vpss ] Terminating Execution...

Eli,

I am referring to ISS_HL_IRQSTATUS_RAW register HS_VS_IRQ bit.

Regards

Rajat