CF7670C vs CF7670C-V2

Managed to get a CF7670C-V2 module in the end, and the available schematic only shows that WRST was replaced by HREF, which is a bit of nonsense, cause in that diagram WRST was left floating. I connected the module and all you see is noise….

Digging further, managed to find the real schematic then all become so simple and obvious: WRST was replaced by HREF on the connector, however, VSYNC is actually driving WRST directly, which means that in a normal scenario, WRST is low during the entire frame and high at te end of the frame, which is wrong unless… you can “invert” VSYNC, which is what OV7670 COM10 registry does:

Once coed changed to set bit 1 and of course change the pin from OUTPUT to INPUT, everything works fine.

For reference, bellow is the schematic with the changes between the two versions:


18 thoughts on “CF7670C vs CF7670C-V2

  1. Thanks for posting this! This explains why my WRST wasn’t doing anything; great of the ebay seller to link to the wrong schematic..

    • You welcome, I had same problem, but managed to get them tell me that WRST was replaced by HREF, but nothing else. Found the schematic only after got it working fine…

  2. Hello and thank you for your helpful post since I’m also trying to get the same module to work.

    I have some trouble understanding the direction of the VSYNC pin, though. I understand that this is an output signal from the camera. So should I connect it to a GPIO pin on my LPC1768 and define this pin as input? When you say that VSYNC is driving WRST directly, you mean that this is done simultaneously (VSYNC is an output from the camera and an input to the FIFO)?

    Forgive me if my questions are too basic but I have a hard time connecting the camera to the mcu.

    Thanx a lot in advance!

    • Hi Manolis, you just need to connect VSYNC (which is output) to WRST (which is input), set your camera module to output and invert VSYNC and should work. Btw, this hardware change is only for first version of the module. Hope this help, good luck!

  3. Hello again and thank you for your response!

    Unfortunately, I haven’t had any luck with the module yet even though I have observed something coming from the camera (I have the second version of the module by the way).

    My biggest problem is how to interpret the data I am receiving and whether I’m close to getting a valid frame or not. I can’t really tell if it has to do with bad coding, bad initialization values for the registers or something in the connection of the camera.

    As I understand it may be difficult for you to post your code publicly, I thought about giving you a link with the code I’m using (which is mostly a modification of desaster’s code who has worked with the same sensor but without the FIFO) and maybe you could give me some guidelines regarding what I should check first.

    Here’s the link to the code:

    Being new to both C programming and the ARM “scene”, I’m not confident at all with my coding skills and so it’s really hard to tell which of all things is wrong.

    If it is of any help, this is what my “frame” looks like so far:

    The way this image is produced is by copying the hex values I’m receiving from the camera (actually I convert them to hex from uint8), pasting them in a hex editor and then saving it as .rgb565. This is another thing I’m not really sure I do the right way. Is this a “legitimate” way to see an image from the camera or is it completely wrong?

    Looking forward to your response, thank you again so much!

    Best regards,


    • First, I can not see the picture for some reasons, any way you can upload it somewhere where I can access it without creating an account?
      Second, your code is a bit confusing, however, will recommend using external interrupt to catch the VSYNC instead of waiting for it. Also, if using FIFO there is no need to wait for HREF as your clock will be used to fetch pixel by pixel the frame content. Something like:

      when (VSYNC_L)
      end when
      when (VSYNC_H AND count == 1)
      ____// VSYNC go from HIGH to LOW
      ____for (x = 0; x < WIDTH; x++)
      ________for (y = 0; y < HEIGHT; y++)
      ____count = 0
      end when

      In order to get it work properly, be sure that the proper OV7670 register are set up properly for your screen size, framerate, pixel clock, image format, etc. Also, the only signals you need to handle are VSYNC (OUT), RCLK (IN), RRST (IN) and OE (IN). Hope this helps

  4. Ok! I think I get your point.

    By the way, “Count” is a generic variable you set to 1 before you read a new frame and then to 0 as soon as the frame ends, right?

    And another thing please. Is it wrong if I set RRST and OE LOW right from the beginning (I mean initialize them to LOW and leave them this way) or do I have to do this every time I read a new frame?

    I tried another free image host.

    Hope you can see it this time. If not, please tell me and I will re-upload it.

    Thank you again for your time!


    • The RRST and OE can start in LOW but when you start reading you need to change RRST to HIGH while keep OE to LOW.
      Looking at the picture now, looks like you do have a problem on how the OV7670 is configured: the upper part of the frame seems to indicate that your frame size configured is not the same with the one you expect. Also the lower part of the frame shows something that looks more like “noise”. I will suggest to review the initialization part, there are many explained samples, for example this one here.

  5. Just saw that I forgot to mention WEN in the above signals.

    So to complete my question: is it ok to set WEN(HIGH), RRST (HIGH) and OE(LOW) from the beginning as I’ve done in the code I sent you or do I have to take care of them every time I read a frame?


    • If you are using the V2 module, WEN can be in HIGH all the time, WRST is feed by VSYNC which have to be inverted using OV7670 registry (as in normal case VSYNC is active in LOW where in this case have to be active in HIGH). Once the frame start AND you are ready to read it, you need to toggle RRST to LOW then to HIGH then set OE to HIGH and generate the RCLK to read the data. Doing this with proper timing (all details are in the FIFO chip data sheet) will get you going. I will suggest using a logic analyzer, will help a lot to determine where the problem may be and how to optimize your code. Good luck!

  6. The problem with the initialization part is that I use the exact(!) same values as the guys working with mbed did. But the result is still what you see.

    I’m now working on implementing an ISR to catch the VSYNC as I’ve never used interrupts before.
    I guess the toggling of RRST and the setting of OE to HIGH could be done inside the ISR. And then I can read the pixels one by one using RCLK, outside the ISR, right?

    Well, I hope to get my hands on a digital oscilloscope some time next week. However, would it be safe to assume that I’m expecting a VSYNC of about 30 Hz (as a result of 30fps) and an HREF of about 3.6KHz (30frames/sec * 120 lines/frame for qqvga)? Should these values be exactly so or am I bound to see some differences?

    I really can’t thank you enough for taking the time to explain how this thing works! I’m working on this project as part of my MSc thesis and I mostly work alone. So…”much appreciated” is the only words I can think of for your answering my endless questions :)


    • Actually VSYNC can vary from 60 Hz to less than 1Hz, depends how you set the registries used to define the divider.also, there is a lot pf room to play with HREF, however, the HREF is useless if you using FIFO module. Just use VSYNC to determine when you need to trigger the WRST then read the pixel details (two bytes!) using RCLK. As long you follow the timing diagram in the datasheet should work.
      The configuration of the camera is a very important thing, will suggest to review the details and understand it properly, else you will not know if is the code or just settings. Get a logic analizer and will get much, much easier. Let me know how it goes.

  7. Hello again Claudiu.

    Well the oscilloscope I was thinking about is not currently available in the university so I only did some studying on interrupts.

    Working along the lines of the pseudocode you posted, this is what I’ve done so far:

    void EINT3_IRQHandler(void)

    if falling edge of VSYNC is detected


    clear interrupt flag;

    c = 1;

    while (VSYNC && (c == 1));

    Set RRST LOW;
    Set RRST HIGH;

    for (j = 0; j FIOSET |= (1 <FIOPIN);
    LPC_GPIO1->FIOCLR |= (1 <FIOSET |= (1 <FIOPIN);
    LPC_GPIO1->FIOCLR |= (1 << 27);}

    for (i = 0; i < 19200; i++)
    {chartohex(qqvgaframe1[i]); chartohex(qqvgaframe2[i]);}

    c = 0;


    So what I'm trying to do is set c to 1 the first time VSYNC goes LOW, then wait until VSYNC goes LOW again (to give time for the frame to be written from the input buffer to the memory array) and then read the frame using RCLK, after I toggle RRST. Also I keep OE LOW all the time.

    The chartohex is a function that "translates" each read byte to hex so as to dump the 2*19200 hex values in a hex editor and display the frame as raw rgb in irfanview.

    Yet I still have no luck.

    All I get is noise:

    and sometimes, during the first few seconds, I might get something like this:

    Another "color combination" I've noticed is this one:

    but again I don't think it is of any use…

    A few days ago I had the idea to put an input signal to the XCLK pin which is defined as Not Connected in the datasheet. For some time afterwards I could only read FFFF values and then it came back to "normal". Do you think that this may have caused a problem to the module? I mean I know my code is most likely incorrect but is there a way to tell if I have a hardware problem, too?

    • @Manolis: the second image looks actually like you are almost there, is just a bit out of sync and colors are off. First image looks like you most likely did not inverted the VSYNC (using module v2 you need to have VSYNC in HIGH during the frame and LOW between the frames). You should never use XCLK as input, is the clock for your camera module.
      I will not recommend using “for…next” loops as are high cpu cycles consumers, use “while” instead. Please do remember that timing is very important for the control signals. You need to “store” one frame in FIFO and only after you push it to your external buffer (RRST HIGH-LOW-HIGH -> OE HIGH -> RCLK, etc), reset FIFO’s content (WRST) then you acquire next frame… Hope it helps.

    • i’m trying to use version 3 as well. the sccb is the same as v2. ive got it initialized fine as far as i can tell. i’m trying to output the data line by line to a tft lcd. im trying to get 320×240. I’ve used Desaster’s code as a reference while reading the datasheets, but im still not there yet. it’s very difficult to find information on the v3. i tried ordering the v2, but they sent me a v3. leading me to conclude the v3 is the same functionality, but different packaging. ive noticed that there is only the fifo buffer on the back, and the circuitry found on the back of the v2 has been placed inside the lens housing instead (smaller packaging probably inspired this for lower manufacturing costs is my guess). please let me know if you have success with your cf7670c-v3.
      i’m only able to get white or black with some noise inbetween.

      • Hi Taylor, i do not have v3 and i can’t find the schematic either. However, looking at pinout, should be pretty much similar except RE may not be connected.
        All you need to control is: WEN (input, active HIGH), RRST (input, active LOW), RCK (input, clock, active on rising) and can use VSYNC (output, i guess HIGH during frame).

        OE and RE set to GND all time and COM10 set for reversed VSYNC should get you started if you follow the correct logic presented in AL422 datasheet…

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s