This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problem interfacing dm6437 + micron MT9D13

Other Parts Discussed in Thread: TVP5146

I have interfaced cmos sensor MT9D13 with DM6437 and used the example program modified with decoder TVP5146. I have connect CDDC[0..7], VD, HD, PXCLK and these signals seem to be good. I have also set 3.3 V to TVP5146_ENABLE to disable bus switch. Cmos sensor is set with I2C routine different from that used in the example. When program arrives to FVID_EXCHANGE, it remain blocked. I have also tried to repeat the same code with TVP5146 decoder, with TVP5146_ENABLE set and using TVP5146 signalconnected directly on the DC_P1, but it doesn't work. If I remove 3.3V from TVP5146_ENABLE pin the decoder works, but I can't use obviously CMOS sensor. What I do wrong?

 

Thanks,

   David

  • The TVP5146_ENABLEn pin simply controls a buffer on the output of the TVP5146.  By driving this signal high you are disabling the output of the buffer.  That way there is no signal contention between the TVP5146 and whatever you put on the header.  So driving that signal high is correct.  My best guess is that you have not correctly configured the sensor.  Do you see any data coming from the sensor?

  • Along the lines of Brad's suggestion, my first thought would be to verify that the pixel clock is running and that you are getting syncs from your sensor. There could quite possibly be more to it depending on how you modified the driver or example code but that would be the place to start, if there is no clock and no syncs than the video driver will never cycle to a new frame and FVID_exchange will block indefinitely.

  • I have measured pxlclk, hd, vd and I also see values of pixel change on CDD[0..7]. Can I  also change the polarity of these signals, but it's important to see the fuction not blocked? I test also to connect signal of tvpdecoder before bus switch with tpv_enable to DC_P1, I see PXCLK, HD, VD signal on DC_P1, but FD_EXCHANGE blocks! I don't know what to check more.

    David

     

  • If the clocks and syncs are functioning than the issue is likely somewhere in how the driver is configured. Along these lines I am curious if you started with an example to try to achieve your interface to the Micron sensor? In particular it may be worth trying out the example within C:\dvsdk_1_01_00_15\psp_1_00_02_00\pspdrivers\system\dm6437\bios\dm6437_evm\src\video\sample\rawcapture as this sets up the capture driver to expect an imager using external syncs instead of the TVP5146 which usees bt.656 embedded syncs.

  • thanks a lot,

    that is the problem! in my code, using a configuration tipical of TVP5146 decoder, I utilize embedded syncs. Now the program is working, I have to set correctly also some parameters in the registers of the sensor.

    But about embedded sync and external syncs, I have supposed, looking the pinout connection, that syncs are exctly the same: pxclk, hd and vd, only change the information of pixels (raw data vs YUV). Which are the differences?

    regards.

  • With embedded syncs the VD and HD signals are not used at all.  The sync signals are represented by a special data sequence (SAV = Start of Active Video, EAV = End of Active Video).  By having this unique representation directly inside the data stream the additional sync signals are not needed.

  • Brad is correct, using embedded syncs means that the receiver can ignore the external syncs, they may still exist but are redundant and not used, at least in the case of the TVP5146 configuration. I imagine that your Micron sensor does not support embedded syncs, so you need to use the external syncs to get communication going, if the clock and syncs are toggling appropriately and you are still stuck on FVID exchange than there is most likely some configuration problem in your code/driver.

    Have you tried out the rawcapture example mentioned earlier in the thread? I know from personal experience that this one will cycle through the FVID_exchange calls as long as you provide a clock and syncs to the VPFE.