We're using the ADV7280 as the input to the ADV212 in encoder mode.The ADV7280 can be setup to output de-interlaced video with EAV/SAV codes. Can the ADV212 accept de-interlaced NTSC? Which VFORMAT setting should be used for this?
Yep, you'd use custom mode VFORMAT=4 and have to program the timings into the pixel interface registers.
We are not seeing any DMA requests from the ADV212 encoder when video from the ADV7280 is driving the VDATA bus The ADV7280 is directly connected to the ADV212 VDATA bus: ADV7280 P[7:0] -> ADV212 VDATA[11:4], ADV7280 LLC -> ADV212 VCLK.
The ADV7280 is set to free-run with the video standard set to NTSC-M. The ADV212 firmware seems to be loading correctly and I get the correct value in SWFLAG after the firmware and parameters are loaded. I have read-back the parameters and they are correct. I have VFORMAT = 0, PREC = 0, XFORMLEV = 5, UNI = 3, CBSIZE = 3, WKERNEL = 0, STALLPAR = 0, ATTRTYPE=0, RCTYPE=1, RCVAL = 0x0028B1, J2KPROG = 0, PICFG = 0x0F, all remaining parameters are set to zero. EDMOD0 = 0x000B.
SCOM[3:0] are toggling but they do not seem to go A-B-C. SCOM pulses high for about 1.5ms and then goes back low for a few hundred ms.
I have tried driving the ADV7280 with live video and it does not make a difference. I'm assuming the ADV7280 in free-run mode produces a video format compatible with the ADV212 with VFORMAT=0.
Any suggestions on how to debug this? Any help at all would be greatly appreciated.
What about COD_STYLE? That must be 1 or 2 or you will never get output.
Assuming ADV7280 in free run produces a format that VFORMAT=0 will recognize as NTSC is a bad assumption. The parts are years apart and it's unlikely more than a few, if anyone, have tried to connect them.
Normally you should see 0-1-2-3-4-5-6-7-8-A-B-C-7-8-A-B-C with the 7-8-A-B-C repeating forever on SCOM[3:0]. It wont be equal time in each state, they vary dramatically. If you never see SCOM[3:0] = '7' then it's not looking for video and your video format doesn't matter yet. Then it's usually you have corrupted firmware in your load (read it back immediately after writing it to verify it) or you have a power problem on the 1.5V role (you need a clean supply that can source at least 1A) or you have a MCLK/VCLK PLL setting problem.
If it gets to '7' and stops, it means there is a problem with your video format.
Getting more detailed information on the SCOM pins is probably what you should be looking at next.
Thanks, Dave. I have COD_STYLE = 0, ADV212 raw format. Is that not a valid COD_STYLE value?
I found in the ADV212 user guide that with 8-bit pixel data on the VDATA bus the part needs VDATA[3:0] driven to 0xf when the EAV/SAV start code 0xff is to be recognized. Is this correct, that on an 8-bit VDATA system VDATA[3:0] cannot be simply tied low? Can this be changed in firmware?
I'm loading firmware file encode_2_18_3COMP_0.sea. Should I be using the earlier 2.13.0 version instead?
Regarding the 1.5V VDD supply, the data sheet specifies a maximum IDD of 440 mA with JCLK at 150 MHz and 320 mA with JCLK at 108 MHZ. I'm using a VDD supply with 600 mA capacity and JCLK is 108 MHz, so the VDD supply should be more than adequate . Is the data sheet not correct?
COD_STYLE=0 is not a valid format. It was at one time, but hasn't been for a very long time.
Unused VDATA pins are supposed to be pulled low, that's not a problem. Where in the user guide did you see that?
The data sheet is correct at steady state but there can be very high power transients on start up that a power supply under 1A capability will likely cause 1.5V to drop out of spec and crash the part unless you have a very high quality power supply with very effective decoupling both on power pins and bulk. It's generally much easier to just use a supply that can go to 1A. If the part is not getting to the SCOM[3:0]='7' state, that power supply is probably your problem.
Page 74 of the user guide seems to indicate that VDATA[3:0] needs to be drive to 0xf when VDATA[11:4] is 0xff. If this is incorrect and VDATA[3:0] can be tied low this is very good news for me,
I'm seeing SCOM[3:0] == 7 most of the time, so the part should be starting up okay. I'm pretty sure there are no VDD start-up issues since i can access the HDATA bus without problem after the part is powered on.
I'll try COD_STYLE = 1 and see if I have better luck with that.
I changed to COD_STYLE = 2 and I'm getting different results on SCOM[3:0] but still no DREQ0. Here is what I see on SCOM[3:0]:
7 for long time (probably between fields)
8 for 1.4 ms
A for 1.4 ms
5 for very short duration, maybe a few microseconds
7 back to 7 for a long time
Ok.. that sounds like your problem is with video format. It's getting things partially but the format is not what the ADV212 expects so it's losing it and throwing out the data probably. What are you using for the BT.656-4 bit in the ADV7280? You might try toggling that (it's probably 0 by default and ADV212 wants it to be 1).
Thanks for all your help Dave. I got it working after I found that the EDMOD0 register wasn't being written properly. After that was fixed it runs perfectly with the ADV7280 and VFORMAT = 0.
Retrieving data ...