DM6435 VPFE SYN_MODE.DATSIZ not behaving as expected/documented

It makes sense that you would lose high order bits if you were supposed to be using a lower width sensor, as sensors are meant to be connected up to the lowest bits on the CCD bus as mentioned in section 2.1.1 of SPRU977a. I believe the shift happening there is just for internal alignment of the processing blocks in the CCDC/VPFE, and is in place to assume that you will use the lower bits of the CCD bus for smaller width sensors as opposed to connecting a smaller width sensor to the upper most bits of the CCD bus. This being said, I suppose the confusion here is over what is meant by a 'right' shift?

What was assumed (incorrectly?) is that I could hook up the 12 bit sensor and shift it right so that I could ignore the bottom 4 bits and process as an 8 bit pixel for faster thruoughput or select all 12 bits for higher precision.  Is there a way to do this with the data formatter section further downstream? 

Please do clarify about the "right shift" in the VPFE.  If I only hook up the bottom 8 bits then what needs shifting???  Really all that is occurring is the masking of the upper bits unless this is also changing the pin functions.  Even that is not a "right shift".

Eric Bryan said:

What was assumed (incorrectly?) is that I could hook up the 12 bit sensor and shift it right so that I could ignore the bottom 4 bits and process as an 8 bit pixel for faster thruoughput or select all 12 bits for higher precision.  Is there a way to do this with the data formatter section further downstream? 

I don't believe that there is, this would require another shifter in the VPSS.  To try to clarify why it is the way it is, if you had an actual 8 bit sensor and if it worked the way you were assuming than it would mean your 8 bits would have had to be hooked up from CCD [11:4] instead of CCD [7:0]. I think the problem is that the shifter is really mentioned at all, since it adds confusion to how you can actually hook up a sensor when it really just appears to be managing internal VPSS alignment.

Eric Bryan said:

Please do clarify about the "right shift" in the VPFE. 

I don't think the shift matters for practical purposes to a typical user, since it is just internal alignment on the VPSS processing blocks, either way the output data you get in memory is going to be clipped to DATSIZ bits that make the most sense, so it does not matter if it is using the upper portion or lower portion of the internal16 bit data bus of the VPSS.

Eric Bryan said:

If I only hook up the bottom 8 bits then what needs shifting???  Really all that is occurring is the masking of the upper bits unless this is also changing the pin functions.  Even that is not a "right shift". 

I am not sure what shifting actually needs to take place, as I am not intimately familiar with the internal structure of the VPSS processing blocks being used in RAW mode, but I can say that it is expecting the least significant bits on the external bus to be connected to a sensor of smaller width, and that setting DATSIZ is going to make sure the VPSS handles a sensor of DATSIZ width properly when connected this way. Additionally since it has no other way of knowing how wide your sensor actually is, if you wanted to do a lower bit depth sampling, your sensor would have to be shifted somehow on to the LSBs of the bus. Unfortunately this makes your particular use case not possible, and I certainly agree that the mention of a shift here is not really helping the clarity of the documentation, and should probably be reworded.

Actually, we configure the pinmux with how many bits the image sensor uses so the information is available to do the shift as I envisioned but its clear from your post it doesn't do what I thought so on to solving the problem of selecting just the 8 bits I want to deal with...

The FMTCFG.VPIN settings will select bits in the Data Formatter section but is 10 bits wide.  Can I then set PACK8 in SYN_MODE to trim these to 8 bits and pack them into a 32 bit int? 

Is there some example code of how to configure the Data Formatter section?  My first pass is resulting in random outputs even with fixed pattern coming from the sensor.   The same app note mention above notes a pixel clock limitation of 75MHz but says it is related to (DSPCLK/3)/2 which is 116MHz with the 700MHz part we are using.

Eric Bryan said:

Actually, we configure the pinmux with how many bits the image sensor uses so the information is available to do the shift as I envisioned but its clear from your post it doesn't do what I thought so on to solving the problem of selecting just the 8 bits I want to deal with...

You make a good point here, you do configure the pins, unfortunately the PINMUX configuration is really seperate from the VPSS configuration, that is you could have pins on the bus not enabled by PINMUX but have the VPSS trying to read values from them anyway, or the reverse having pins exposed by PINMUX that the VPSS ignores.

Eric Bryan said:

The FMTCFG.VPIN settings will select bits in the Data Formatter section but is 10 bits wide.  Can I then set PACK8 in SYN_MODE to trim these to 8 bits and pack them into a 32 bit int? 

I am not sure that this is possible, as section 4.3.1.4.5 mentions specifically that the output format is directly determined by the DATSIZ parameter and that the PACK8 setting is only available in 8 bit input or A-Law from 10 bit input, which implies to me that even if you are using the data formatter that you will end up with the values in SDRAM in the width format that you took in from the sensor.

This is somewhat ambiguous though, since the data formatter block downsamples to 10 bits which looks to be possible to A-Law compress down to 8 bits which can be independent of the DATSIZ input, I will have to check on this one internally.

Eric Bryan said:

Is there some example code of how to configure the Data Formatter section? 

I am afraid I do not know of any, the EVM only really uses the bt.656 capture mode, so I have not done too much work with RAW, at least in regards to processing the RAW image data in the VPSS.

Eric Bryan said:

My first pass is resulting in random outputs even with fixed pattern coming from the sensor.   The same app note mention above notes a pixel clock limitation of 75MHz but says it is related to (DSPCLK/3)/2 which is 116MHz with the 700MHz part we are using.

The pixel clock being used on the DM6467 must not exceed 98MHz for the VPFE alone, or 75MHz if the VPBE is also being used with the same clock, this is a limitation of the VPSS hardware itself, and though the VPSS is related to DSP/3 clock rate in its internal connections, the pixel clock externally cannot safely exceed the maximums perscribed by the datasheet.

I can run 12bit input with PACK8 set and it works as expected.  I just want to use the Data Formater now and select which 8 I want...

My code for setting up the VPFE follows (not PACK8 enabled)..

static void initVPFE( Image_struct *image )

{

            VPSS_PCR = 0;            // clear any junk errors

            CFG_VPSS_CLKCTL = 0x00000000;

            VPFE_CCDC_CCDCFG =          0x00008000;      // Necessary for proper vpfe function

            VPFE_CCDC_SYN_MODE =      0x00030400;      //* 12 bit raw with hd/vd as inputs stored as 2 bytes

            VPFE_CCDC_HORZ_INFO =      (0 << 16) |        

                                                                                    image->ROI.LengthX-1;

            VPFE_CCDC_VERT_START = 0;  //*

            VPFE_CCDC_VERT_LINES = image->ROI.LengthY-1;

            // row boundaries are stored in memory but must fall on

            // 32 bit boundaries...

            if ((image->ROI.LengthX) & 0x1F)

                        VPFE_CCDC_HSIZE_OFF = ((image->ROI.LengthX) & 0xFFE0)+ 0x20;     // need to round up

            else

                        VPFE_CCDC_HSIZE_OFF = image->ROI.LengthX;

            VPFE_CCDC_SDR_ADDR = (Uint32)(image->Image);

#define ENABLE_SHIFT

#ifdef ENABLE_SHIFT

            VPFE_CCDC_FMTCFG=0x0000E000;

            VPFE_CCDC_VP_OUT=(image->ROI.LengthY-1)<<17 +

                                                            (image->ROI.LengthX)<<4;

            VPFE_CCDC_FMT_HORZ=image->ROI.LengthX;

            VPFE_CCDC_FMT_VERT=image->ROI.LengthY;

            VPFE_CCDC_SYN_MODE=0x00070400;            //* 12 bit raw with hd/vd as inputs stored as 2 bytes

#endif

            VPFE_CCDC_VDINT = ((image->ROI.LengthY/2) << 16)   // VDINT0          set to half way just for testing

                                                            | (image->ROI.LengthY-1);                                  // VDINT1

Values stored in the frame buffer with above code:

full_frame         

0x031F009F      0x00800040

0x00200010       0x00080004

0x03B600B7      0x00930259

0x039503BB      0x00080004

0x03CD03FD     0x00000000

0x023E03AB     0x00AB02D6

0x036B039E      0x00000000

0x02000100       0x00800040

0x02F903FC      0x00000000

0x039D01BB     0x00800040

0x02F903FC      0x00080004

0x02F903FC      0x00800040

0x00200010       0x00080004

0x02F903FC      0x00000000

0x02F903FC      0x033B0258

0x0214039B      0x00000000

0x02F903FC      0x00800040

0x03F903B4      0x03A703AD

0x02BF03BB     0x00800040

And these change.  The values like 0x00800040 and 0x00200010 are what I expect but not always in the right memory locations.  Its like the timing is off somehow.  The VPSS_PCR register is showing zero after the image is acquired so I don’t think there is any sort of overrun.

If I do not define “ENABLE_SHIFT” I get

full_frame         

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

0x00020001       0x00080004

0x00200010       0x00800040

0x02000100       0x08000400

These are what I expect and I get the same values every time.  A timer loop I’m running shows the same period has elapsed for both image acquisitions.

Any clues?

Sorry for the delay on this, I am still looking into this one internally and trying to find out how to best achieve your goal.

As to the settings you are using, the register values you write out seem reasonable to me though one thing kind of sticks out and that is you do not have any offsets in the FMT_HORZ or FMT_VERT registers, and based on figure 54 on page 88 of SPRU977a it seems like the VPSS data formatter may be expecting values that are smaller than the global frame, and since the offsets are relative to the sync they would have to be greater than 0. Note that I am not sure that this would actually fix anything or not, as I do not know of any good examples of leveraging the data formatter (which is something I am looking for) to really compare to, however I have seen other situations in the VPSS where if offset requirements (or really any size/timing related settings) are not met that you can end up with strange data output.

Another thought would be if you see the data change at all if you look deeper into the image, it is possible that the first few lines may be corrupted and the bulk of the image is ok.

Zeroed the image array before every acquisition and checked further.  Data appears to only cover two rows.  I changed the row/column size and the image array still only changes for the first two rows.  All others appear as zero.

Added a value of 2 offest in the FMT_VERT and FMT_HORZ (and decreased CCDC_VERT_LINES and CCDC_HORZ_INFO by 2).  I get two rows of corrupt data that are two pixels shorter.  SPRU977A says zero is valid for these so I didn't expect much but it was an interesting theory.

I mark image done based upon VDINT so I assume I am clocking out to DDR the expected number of pixels.  (It also works without the format section being turned on and takes the same amount of time whether I turn the format on/off).

I will look more with an eye to why only two rows are being changed.  I am coming up on an internal deadline.  Is there any time estimate on when you will get more feedback?  If we have to hardwire for specific bits we will reduce the functionality of our device.

Eric Bryan

Just to be clear on what your goal is, you want the VPSS to capture data from CCD[12:4] and have that placed into the LSB of half words of DDR memory?

Eric Bryan said:

Zeroed the image array before every acquisition and checked further.  Data appears to only cover two rows.  I changed the row/column size and the image array still only changes for the first two rows.  All others appear as zero.

This is kind of disconcerting, while I am not intimately familiar with the internals operation of the VPSS processing blocks this makes it sound like we have some bad configuration, my suspicion is that the two rows happen to be about the size of an internal buffer in the VPSS, so it is pumping out something that happened to be in there but not actually getting data from the rest of the frame, which corresponds with seeing junk values. Is it possible for you to take a register dump of the VPSS configured for your capture? This would make for an easier analysis of your settings.

One other thought, if you are getting 0 values output is to ensure the CULLING register is not enabled (i.e. CULLING should be 0xFFFF00FF), I have had instances in the past where culling was inadvertently enabled and blanking all data to a frame, though since you have other modes that work this is probably not the case.

Eric Bryan said:

Is there any time estimate on when you will get more feedback?

If by feedback you mean a fix it is hard to say, currently we are debating if this is possible to do. It is still being discussed if the data formatter will allow you to get down to 10 bits, but there is no way of getting the 8 bits you were originally looking for outside of PACK8 or A-law compression which I suspect is not viable.

Bernie Thompson said:

Just to be clear on what your goal is, you want the VPSS to capture data from CCD[12:4] and have that placed into the LSB of half words of DDR memory?

Ultimate goal is to be able to select any 8 contiguous bits of the 12 for storage to DDR2 for further processing.

Bernie Thompson said:

Is it possible for you to take a register dump of the VPSS configured for your capture? This would make for an easier analysis of your settings.

Can do.  Will get it back to you shortly.

Bernie Thompson said:

One other thought, if you are getting 0 values output is to ensure the CULLING register is not enabled (i.e. CULLING should be 0xFFFF00FF), I have had instances in the past where culling was inadvertently enabled and blanking all data to a frame, though since you have other modes that work this is probably not the case.

Will check this but I am not (knowingly) setting the CULLING register so it should just default.

Bernie Thompson said:

If by feedback you mean a fix it is hard to say, currently we are debating if this is possible to do. It is still being discussed if the data formatter will allow you to get down to 10 bits, but there is no way of getting the 8 bits you were originally looking for outside of PACK8 or A-law compression which I suspect is not viable.

I mentioned before that running without the formatter and engaging PACK8 did what I expected.  If I can use the 10 bit selector from the formater and then engage PACK8 I think this will result in the desired output.  I am checking with the owners of the downstream processes to see if it might be possible to use the A-Law compression as that has another bit selector and you mentioned that was used with the PACK8.

I did notice that the header file for the DM6435 has a number of CCDC registers listed under the formatter that are not documented. 

#define VPFE_CCDC_FMT_ADDR0     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x64 )
#define VPFE_CCDC_FMT_ADDR1     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x68 )
#define VPFE_CCDC_FMT_ADDR2     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x6c )
#define VPFE_CCDC_FMT_ADDR3     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x70 )
#define VPFE_CCDC_FMT_ADDR4     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x74 )
#define VPFE_CCDC_FMT_ADDR5     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x78 )
#define VPFE_CCDC_FMT_ADDR6     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x7c )
#define VPFE_CCDC_FMT_ADDR7     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x80 )
#define VPFE_CCDC_PRGEVEN_0     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x84 )
#define VPFE_CCDC_PRGEVEN_1     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x88 )
#define VPFE_CCDC_PRGODD_0      *( volatile Uint32* )( VPFE_CCDC_BASE + 0x8c )
#define VPFE_CCDC_PRGODD_1      *( volatile Uint32* )( VPFE_CCDC_BASE + 0x90 )

Is there any need to set values in any of these?

Eric Bryan

0-24 are registers from CCDC after image is acquired.  VPFE would have been disabled after the image interrupt.  Other than that no programmatic changes to the registers should have been made.

ALaw selector followed by PACK8 does what I expect -- compresses a selected 10 bits down to 8 and packs into a 32 bit integer.  But Alaw is unacceptable downstream.

Trying to simplify--Is it possible to just select and pack the upper 8 bits of a 12bit sensor without using the core?  I can get the bottom 8 bits by just turning on PACK8.

Eric Bryan said:

Ultimate goal is to be able to select any 8 contiguous bits of the 12 for storage to DDR2 for further processing.

Unfortunately it seems this is not possible without using A-Law.

Eric Bryan said:

I did notice that the header file for the DM6435 has a number of CCDC registers listed under the formatter that are not documented. 

#define VPFE_CCDC_FMT_ADDR0     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x64 )
#define VPFE_CCDC_FMT_ADDR1     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x68 )
#define VPFE_CCDC_FMT_ADDR2     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x6c )
#define VPFE_CCDC_FMT_ADDR3     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x70 )
#define VPFE_CCDC_FMT_ADDR4     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x74 )
#define VPFE_CCDC_FMT_ADDR5     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x78 )
#define VPFE_CCDC_FMT_ADDR6     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x7c )
#define VPFE_CCDC_FMT_ADDR7     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x80 )
#define VPFE_CCDC_PRGEVEN_0     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x84 )
#define VPFE_CCDC_PRGEVEN_1     *( volatile Uint32* )( VPFE_CCDC_BASE + 0x88 )
#define VPFE_CCDC_PRGODD_0      *( volatile Uint32* )( VPFE_CCDC_BASE + 0x8c )
#define VPFE_CCDC_PRGODD_1      *( volatile Uint32* )( VPFE_CCDC_BASE + 0x90 )

Is there any need to set values in any of these?

These should be considered reserved and left alone.

Eric Bryan said:

Trying to simplify--Is it possible to just select and pack the upper 8 bits of a 12bit sensor without using the core?  I can get the bottom 8 bits by just turning on PACK8.

I don't think this is possible, at least without A-law, it seems that the data formatter should output to the 10 bits of LSB however this is not enough to get you to that 8 bits to use the PACK8 format. And if you were going to use A-law you would not need the data formatter anyway since you can select the bits that go into the A-law block with ALAW.GWID. It seems the only way to do this is to use an external mux or to reformat the data in software, if I am able to come up with any better way to do this I will be sure to let you know.

OK, I can't use ALaw.

But are you saying it is also impossible to get the data formatter section to work? PACK8 is working on incoming 12bit data.

Eric Bryan said:

But are you saying it is also impossible to get the data formatter section to work?

The data formatter only outputs 10 bit wide data, it will not get down to 8 bit.

Eric Bryan said:

PACK8 is working on incoming 12bit data.

But you say it only works on the lower 8 bits of the 12 bit bus, you can get the upper 10 bits of your 12 down to the lower 10 bits internally through the data formatter, but you cannot do the next shift two more bits to the LSB to get down to 8 bit so that PACK8 would be getting the right bits.

If we can get the data formatter working, it will take care of at least some of the processing load that we will have to handle with the core until new boards are made with new wiring.

When I turned on PACK8 it just took the lowest 8 bits and moved those to DDR.  If I shift the upper 14 bits down I'm expecting it to put only the lowest 8 out to DDR so I should be fine. 

Even limited to 12 bits the data formatter will still give me 2 more bits of dynamic range.

VPIN of 2 would put bits 13-4 on the bus.  PACK8 would mean only bits 11-4 would be put in memory.

What am I missing?

Now I see what you are saying, use the data formatter to overshift the image by two bits, meaning the upper two bits in the data formatter are indeterminate but that should not matter if using PACK8, in theory. Of course this assumes that the VPIN value has no reliance on the DATSIZ that is not shown outright, since bringing in bits outside of the DATSIZ width is not a typical use case (probably not tested), but is definately worth a shot.

Ill have to take a closer look at your register settings to see if I can find any inconsistencies that may be causing the issue when enabling the data formatter.

Thanks!  I'm still trying to dig into the data length discrepancy.  I am working with disabling the interrupt and just waiting for a timeout.  Something seems amiss there.  As usual, it may be more than one problem...

Eric Bryan

The register settings look alright for the most part, attached are my notes going through your settings, the one piece that is missing is the VP_OUT register setting, so you just want to make sure that VP_OUT.HORZ_NUM is less than 5504 and practically greater than NPH+offset (0xA8F = 2591), also VP_OUT.VERT_NUM must be less than FMT_VERT.FMTLNV (0x789 = 1944).

The only other thing that stuck out at me in this is the VPEN bit, particularly since looking at several of the figures based on figure 52 in SPRU977a it is made to look like VPEN is what sends the video data into the preview engine, though figure 14 makes it look like this can go to SDRAM directly. I can take a look to see what I can figure out regarding VPEN and its implications, maybe that will lead us somewhere.

    VPFE_CCDC_VP_OUT=(image->ROI.LengthY-1)<<17 +
                    (image->ROI.LengthX)<<4;

I was checking the results of using the formatter and the PACK8 and saw that it was dealing with one row only, not two like I stated earlier (forgot that it was 2 bytes per pixel when not packed).   Perhaps this helps narrow the problem down since apparently the row never increments.

As for sending the formatter data to the DDR  the document says you can:

The Video Port/Data Formatter output can also be saved to DDR2 instead of the RAW CCD data. The
setting SYN_MODE.VP2SDR sends the Video Port data to the CCDC's Output Formatter. In addition, the normal DDR2 write enable (SYN_MODE.WEN) also must be enabled to store the output to DDR2.

But perhaps I need to have the preview engine turned on even if I don't need its output?

Lastly, could this be an issue with just the DM6435--it doesn't have a physical video out port.

I am still digging around internally to see what we can come up with, hopefully I can get some example settings for the data formatter. Is it a correct statement that you have never gotten a valid frame in memory when enabling the data formatter with VPEN?

One thought on this, to remove any ambiguity in the settings down the road you may want to try using DATSIZ width of 14 instead of 12, so that when you select the bits with the data formatter's VPIN you will be getting known values on the upper two bits, though this should probably work either way.

Eric Bryan said:

But perhaps I need to have the preview engine turned on even if I don't need its output?

I am hoping not, but this should be answered if I can get a hold of some example settings.

Eric Bryan said:

Lastly, could this be an issue with just the DM6435--it doesn't have a physical video out port.

This should not be an issue, these are all hardware blocks that are either part of or directly in support of the VPFE capture port on the DM643x, so they are all there on a DM6435.

Bernie Thompson said:

Is it a correct statement that you have never gotten a valid frame in memory when enabling the data formatter with VPEN?

Correct.

Bernie Thompson said:

One thought on this, to remove any ambiguity in the settings down the road you may want to try using DATSIZ width of 14 instead of 12, so that when you select the bits with the data formatter's VPIN you will be getting known values on the upper two bits, though this should probably work either way.

I'll try almost anything if it will help.  I have tried selecting lower bits/mid bits/upper bits so this should not be an issue but who knows...

Bernie Thompson said:

This should not be an issue, these are all hardware blocks that are either part of or directly in support of the VPFE capture port on the DM643x, so they are all there on a DM6435.

My thought here was that these features are all labeled with names that imply supporting the video output function.  I don't know what the internals of the chip would do without the output hardware being there.  Sort of like switching on an open-ended, unterminated bus lacking pull-ups/downs etc.

Data Size change is no effect.

Internallly we are still digging into this, unfortunately it does not look like we have any code samples of using the data formatter, but we are still confident we can get it to work for you.

I believe you are not using the H3A or the Previewer blocks correct? I ask because one thought that had come up was errata advisory 1.13.12.

Just to be clear, the normal capture of all 12 bits goes fine, the only problem comes in when enabling the data formatter and going for the 8 bits? Assuming this is the case you should be able to  set SYN_MODE.VP2SDR=1, FMTCFG.VPEN=1 along with the VPIN setting to enable the data formatter. One thing I would like to check in this case is that the reserved lower 12 bits of FMTCFG stay as 0, is this what you are seeing?

Bernie Thompson said:

I believe you are not using the H3A or the Previewer blocks correct? I ask because one thought that had come up was errata advisory 1.13.12.

I am not using the H3A or the Previewer for these tests.  I don't know if we will try to use them later or not.  I think they have issues with the raw data format.  At least the Previewer does.

Bernie Thompson said:

Just to be clear, the normal capture of all 12 bits goes fine, the only problem comes in when enabling the data formatter and going for the 8 bits? Assuming this is the case you should be able to  set SYN_MODE.VP2SDR=1, FMTCFG.VPEN=1 along with the VPIN setting to enable the data formatter. One thing I would like to check in this case is that the reserved lower 12 bits of FMTCFG stay as 0, is this what you are seeing?

The problem comes in when enaging the data formatter in any form.  I want to use it to go to 8 bits but I can't even use it to select 10 bits as it is clearly designed to do.  I checked the bits on all the CCDC registers and they have the default values or values I programmed (I double checked the ones you listed and they are set and cleared as specified) according the SPRU977A except for CLAMP.  That register is showing OBGAIN as 0x10 where SPRU977A says it should be 0 by default.  CLAMPEN is 0 so I don't see that this matters in my case but something is amiss.

To start, the values you have look ok, everything seems to be configured properly to enable the data formatter, so we need to figure out why it is locking up. To try to debug this further we would like to try a set of frame sizes that are safer, that is, based on 16 and 32 bit multiples where each successive frame is guaranteed smaller than the previous flowing through the data formatter (see figure 54). This may not get you the actual image output you want from a size stand point, but if we can get data flowing through the formatter than we can try tuning the values from there. Since I do not have a good setup to test this on I was hoping you could try to input some of these values into your program to see if you can get some valid output in your memory buffer. I am assuming from your register settings that your sensor source is providing a 2592x1944 for these values, that is, if you had embedded syncs you would have PPLN=2592 and HLPFR=1944, though these fields are ignored with external syncs.

//enable the data formatter
FMTCFG.VPEN = 1
FMTCFG.VPIN = 2
SYN_MODE.VP2SDR = 1
SYN_MODE.WEN = 1

//first pass formatter
//we take 32 pixels off of either side, an overestimate
FMT_HORZ.FMTSPH = 32 //horizontal offset from start of HD pixels first pass
FMT_HORZ.FMTLNH = 2528 //width of valid data area in pixels first pass

//we take 16 lines off of top and bottom rounding to a multiple of 16 count, another overestimate
FMT_VERT.FMTSLV = 16 //vertical offset from start of VD lines first pass
FMT_VERT.FMTLNV = 1904 //height of valid data area in lines first pass

//second pass formatter
//we cut off another 32 pixels and 16 lines, but leave the horizontal offset for 0 for now, there is no vertical offset
VP_OUT.HORZ_ST = 0 //horizontal offset from first pass
VP_OUT.HORZ_NUM = 2496 //width of valid data area in pixels second pass
VP_OUT.VERT_NUM = 1888 //height of valid data area in lines second pass

//final pass before sending to DDR
//we cut off another 32 pixels on either side
HORZ_INFO.SPH = 32 //horizontal offset from second pass
HORZ_INFO.NPH = 2432 //width of valid data are in pixels final pass

//we cut off another 16 lines off the top and bottom from both fields
VERT_START.SLV0 =16 //vertical offset from second pass field 0
VERT_START.SLV1 = 16 //vertical offset from second pass field 1
VERT_LINES.NLV = 1856 height of valid data area in lines final pass

The goal here is to attempt to satisfy the equations:
PPLN > FMT_HORZ.FMTSPH + FMT_HORZ.FMTLNH > VP_OUT.HORZ_ST + VP_OUT.HORZ_NUM > HORZ_INFO.SPH + HORZ_INFO.NPH
 
And

HLPFR > FMT_VERT.FMTSLV + FMT_VERT.FMTLNV > VP_OUT.VERT_NUM > VERT_START.SLVx + VERT_LINES.NLV

While keeping the values on 32 bit boundaries, so we have:

2592 > 32 + 2528 > 0 + 2496 > 32+ 2432

1944 > 16 + 1904 > 1888 > 16 + 1856

Giving us a final image size of 2432x1856 in this setup, as a test. As mentioned above this is not a guaranteed fix, but just a test, if I had this setup here this would be one of the first things I would try, as we are trying to follow the implied use shown in figure 54, along with keeping on 32 bit boundaries to ensure that having the odd value widths are not impacting the formatter block somehow.

Working on this.  I hope to have results for you tomorrow. 

good and bad news...

This seems to take care of the "garbage data" issues.  All values I see are valid, in sequence, as expected.  I am getting more than one row of data.

Bad news:

Total number of bytes transfered is 2580416=1290208 pixels which I don't think corresponds to any integral multiples of any row or height parameter we set.

Data includes values like 0x08000400 as well as 0x00020001.  This means that the shifter in the formatter is not being engaged. We are getting more than 10 bit data out.  It may be possible that we are not going thru the formatter at all.

I did run additional tests with a couple differences in SYN_MODE.  I started using your specifications exactly:

VPFE_CCDC_SYN_MODE=0x00060000;   

and then tried the following which is what I ran before and think it should be:

VPFE_CCDC_SYN_MODE=0x00070400;    //* 12 bit raw with hd/vd as inputs stored as 2 bytes

This change made no difference in the stored image data.  I also tried 0x00060400 again with no change in the stored image data.

I am glad to hear that there is some output with the data formatter enabled, even if we are not all the way there yet. The register settings I gave before were incomplete, meant to be more of modifications of existing settings that you have working for 12 bit capture mode, I apologize for the confusion there.

Eric Bryan said:

Data includes values like 0x08000400 as well as 0x00020001.  This means that the shifter in the formatter is not being engaged. We are getting more than 10 bit data out.  It may be possible that we are not going thru the formatter at all.

Though this data does appear off, I am curious if it works properly when you use PACK8? I was under the impression that you planned on using 8 bit packed data in this capture mode we are working on?

Eric Bryan said:

I did run additional tests with a couple differences in SYN_MODE.  I started using your specifications exactly:

VPFE_CCDC_SYN_MODE=0x00060000;   

and then tried the following which is what I ran before and think it should be:

VPFE_CCDC_SYN_MODE=0x00070400;    //* 12 bit raw with hd/vd as inputs stored as 2 bytes

This change made no difference in the stored image data.  I also tried 0x00060400 again with no change in the stored image data.

As mentioned above the settings were not meant to be a complete set, but changes that should be made to enable the data formatter from an alread configured VPFE, my one thought here is regarding using a DATSIZ value of less than 4, I assume this does impact the resulting output?

I implimented your settings after my regular settings but it was not a "bit-wise OR" of the combination.

I am planning on using the PACK8 and will try and test that this evening along with some other DATASIZ values.

I want to work at enabling your settings a few at a time and find which one caused the random data to disappear and see if I can get the formatter to trim the image output in the manner described in the documentation.  Right now I just have an output block but can't really relate it to rows/columns.  I can change our test pattern output and try and gain a little more insight.

Is there anything you can think of to change that would possible engage the shifter in the formatter?

Eric

I look forward to your PACK8 results and it sounds like you have a sound plan for digging into this further, I would agree that taking back settings until you get the prior failure pattern should help to point us in the right direction.

Eric Bryan said:

Is there anything you can think of to change that would possible engage the shifter in the formatter?

The formatter VPIN selection/shift bits should be active as soon as the VPEN is enabled for the data formatter and VP2SDR is enabled to select the output from the data formatter to write to DDR, this should be all you need to have that 'shifter' engaged. The other register fields just configure around it, which unfortunately could lead to problems if the various sizes and counts do not agree, though with the suggested settings any possible requirements in this regard should have been met, the best way I can see to proceed is to try varying settings between what  you had and what I posted earlier to see what settings are having an impact and go from there.

I am still very concerned that the data in memory shows no indication that the 10 bit selection/shift in the formatter has occured.  It is very possible that the formatter is still not enabled.  If I can decipher the rows/columns we will be closer to knowing whether the formatter was actually enabled.

Manipulated our test pattern and determined that the DSP is passing 2528 pixels per line.  As I had not changed the PIX_LINES register the previous run must have had gaps in the row data.  I noted the gap of 64 bytes when I changed the data.

Just enabling PACK8 does pack the data as expected.  I only calculated 1240 bytes(pixels) per row?  I think had made some settings for HSIZE_OFF that are interferring with this so I am not too concerned about this point--it should be an easy fix. 

Based upon the size, we are getting the frame trimmed based upon the formatter.  I will try and get it trimmed up properly tomorrow and have few concerns about that.  I will also try and isolate the setting that caused the random data.

But I am still getting high order bits set in the output.  I put a test patterns thru that had upper bits set and they are not getting selected/shifted down. I always get the full 12 bit value.

Some success!

Noted that FMTCFG was different between old and new.  Turns out old setting was right, new setting was not setting VPEN.  Set that bit and now it appears to be at least masking the bits.  Was late and I didn't try a setting that would do shifts.  I will try that and then proceed thru the other registers (again!) and see what is fouling up the output.

I really appreciate your help.  Having a valid output makes it much easier to make a change and see the results.

I am glad to hear that data is flowing and appears to be masked, hopefully this means you are very close to having the shifted data. I am looking forward to your end results, as I am curious why it was not working with the initial register set, we should be able to determine what register dependencies there are that were initially overlooked.

That is great news, so you are now getting the total image you needed bit shifted correctly, and all is well? This would explain seeing the lesser amount of data being placed into memory, and seeing junk values, though this is unfortunate it is typical, if the values put into the CCDC do not align properly you can end up with strange results.

Eric Bryan said:

Only thing more I could ask for is for the output to be 0xFF if I select the lower bits and one the upper bits is set?

You mean like a saturation function? I am afraid I do not know of a way to do that with the VPFE, at least I dont think that funcationality is the intent of any of the processing blocks in the VPFE.