I started to look for a digital solution to achieve Ambilight like functionality. I ended up with this design which is far from economical for such a task but I rather choose overkill than to fall short on resources during sw development.
IO is pretty limited, but utilizing the power of the Xilinx SoC the board might be used for other (possibly more serious) purposes too.
My excuse for doing something non-sustainable here is that I miss the days from my former job where I had to do hardware design for a living and I needed some practice before I forget everything :)
-Xilinx ZYNQ Z7010 SoC (with config flash, no external DRAM)
-Analog Devices ADV7611 HDMI receiver (professional version without embedded HDCP keys)
-FTDI FT230X USB-UART
-8 5V outputs on 24pin header for RGB LED strip control (for e.g. WS2811)
-Credit card sized board (~85x54mm)
Ok, last day of vacation. Tomorrow I'll try to integrate myself back to work to be a useful part of society. On this day I should've presented you the working system. Well I guess I'm a bit behind. :P
So I2C. The AD7611 has a quite strict read sequence. First you have to address it in write mode, sent the sub-address (register address) then re-address it in read mode to get the value from it. The trouble comes from the fact that between the initial write and then the read transactions there can not be a normal bus stop-start cycle because then the chip won't respond.
What do you think can the ZYNQ PS I2C driver (hw?) do this?
NOPE. At least not the latest one. Strangely if I do some very-very unprofessional text edits in the SDK source files, then it lets me to use an older revision of the driver (2.2 instead of 2.3) where there is a Repeated Start Condition option. This seems to solve the issue. According to the changelist this was removed from 2.3 wihtout stating the reason.
I found several forum entries both on Xilinx and Analog Devices websites related this issue. There are some quite popular ZYNQ boards out there that has an ADI ADV7511 for HDMI output. That chip has the exact same isse, and unfortunatelly there was no proper solution presented for this case.
I have to admit that I highly underestimated this problem too during planning. I've worked with a lot of different MCUs (mostly simple ones though) and a few FPGAs and I didn't really expected that simply running my application code will give me this much headache.
I was expecting something similar for the ZYNQ what I would see for any Xilinx FPGA with a MicroBlaze soft CPU in it. The chip can control configuration for itself, it will load everything from the configuration flash memory and executes the included software binary on the processor.
In case of the ZYNQ, the processor handles everyhing and the FPGA part (PL) is just like any other perfipheral for it, that needs to be configured from software. This in itself wouldn't be much trouble, Xilinx even supplied a wizzard in the SDK that creates a nice so called FSBL (First Stage Boot Loader) that will search the config memory for the FPGA bitstream and application images, checks and loads everything and make life very, very easy...
...in case you have external DDR SDRAM attached. If not well, you're scr*wed. Of course now after a week of struggle the whole thing seems simple. Now I know what modifications needed to be done in the generated FSBL (there are some tech tips on the Xilinx website which gives guidance) to work without external memory, but a few days earlyer I started to become quite desperate.
My current dilemma is that I'd like to do this neat and nice, so that the application itself is a separate image, loaded by the FSBL, this way I could save some valuable on-chip memory (OCM) space and also resue the FSBL for different projects. I could execute the FSBL in execute in place (xip) mode directly from the flash, so that it doesn't get loaded into the OCM, and it can copy the application binary there. However even if executed from the flash, the FSBL still needs to have it's data sections to be in the OCM. In this case how should I partition the most precios 256kBytes of OCM? (.bss + .data for the FSBL is around 75kBytes)
I think I'll just merge the FSBL and the app sw itself to have a single binary that is automatically loaded at startup. It will load the bitsream but does not look for further images on the flash and will not handover execution it will just simply start doing what the app software should. This way I can start writing actual application code tomorrow.
Or even more alive. At least I hope since I haven't yet checked the ZYNQ. I had to give it a few more runs with IR and I fear that the BGA joints don't tolerate this stress well. But at least most of the stuff is up, and it doesn't smoke.
At least the ZYNQ is. After yesterday's trouble I was pretty pessimistic, but the ZYNQ started up fine for the first time. All PL IOs seem to be ok, and I could run a software debug session from the Xilinx SDK.
Oh yeah, the config flash... thermal pad upside?! Guess who draw a mirrored footprint! Of course it was me. So dead bug is the new way to go. (I'm glad though that I didn't have to do sg like this :D )
First I realized that I made a very very ameteur mistake by last minute editing the outgoing gerbers manually. Wanted to spare a couple of hours -> connected power and gnd plane... congratulations.
Never ever, again.
I had to mill out the plating from the slots of the DC power receptacle. The short is gone, but now I have to live with some wires soldered to the board as a power input. Luckily I have these large test-point pads all over and I also had a nice pair of VCC IN and GND where I could connect the wires at least.
The next thing was the psu. Do you see the components marked as U2,U3,U4. Those are TI LMZ10501s which is a 1A rated buck switching regulator with integrated inductor. 0603 components and 0.1" header for scale! Yes, that thing is small, and btw is super awesome, but it has 8 flat leads + 1 big pad beneath. It took me like 10 runs with the rework station and a whole day to have all three soldered correctly.
Plus I gave up my view on lets not mix things what should not be mixed and I started to use leaded solder because the Pb free gave me more headache than I was willing to tolerate. (PCB has lead-free HASL beacause that was a lot cheaper than leaded and I wanted some solder on the pads in hope of not needing paste for the BGA. Otherwise I would've went for ENIG.)
Tomorrow: BGA yeeeah. I'm a bit sceptical about success at first trial. If by some miracle I manage to put that up properly, I'm done with the hardest part. The rest is hand-solderable and should couse no serious problem. Fingers crossed.
I was hoping that the solder on the board from the HASL process together with the solder balls on the CSP and some good flux will be enough. I did this a few times successfully with 1mm pitch BGAs and leaded solder. However now this is 0.8mm Pb-Free. The more I read about it the worried I become.
Alternatively I could order something as a StencilQuick permanent polyimide stencil (75 bucks for a 10pc pack if I understand it right), this would even help placement, however the 125USD shipping fee makes me a bit reluctant.
I could ask for a small steel stencil where the PCBs beeing produces for like 40-50EUR but then I need to fix them properly in place, deal with lifting and after that somehow place the chip into proper position because I don't have equipment for that.
All the articles I found were either about rework, so dealing with cleaned pads, or about mass production onto empty pads. I have no clue how this will turn out for my case. Maybe I'll just try the first one (54USD for a single ZYNQ) and if that fails order some stencils, but that would risk that I can work on this in my winter holiday.
I'm thinking on creating a test firmware that toggles all IOs at least from the PL (FPGA part in the ZYNQ), this way before populating the series resistor array I could even check if inputs are connected properly. I could run this test before soldering the rest of the expensive components.