Project: HDMI/DVI out for STFM

[troed]

Does anything change with the clocks at all from the shifter being inserted to the FPGA board ? Does any clock lines get different loads between shifter vs FPGA ( I don't really know how its all hooked up in your machine or how the FPGA clocks are working )

If we disregard it happening on my doubleST where no, the FPGA cannot affect my clocks, then yes - replacing the Shifter with the FPGA might indeed change a lot regarding the 16MHz clock to the MMU (from which all other clocks are derived). However, I don't think I have resets due to that on my 520ST and resets (more often) due to a completely different issue on my doubleST.

So ... I'll just LA the crap out of everything and maybe scope VCC etc when the resets happen to see if I can get a clue. I think it's pretty weird. It's really an instant reset and RESET does trigger when measured on the CPU.

In the stock FPGA version it has its own 32.000MHz oscillator (so yes, you can now check demo compatibility ) and it outputs 16MHz to the MMU just as a regular Shifter. For my doubleST uses we've changed so that I provide the 32MHz clock to the FPGA (and have removed its oscillator) from my GAL.

(I'll keep further doubleST-only comments in my thread on the subject to not confuse readers who only want to know about the FPGA-as-is

[exxos]

Been running GB6 for 4 hours now .. no problems at all...

I guess the 32MHz feed is the thing which was being talked about before...

I think if the 32MHz from the STFM went into a schmitt buffer, it should be good enough to feed the FPGA.. if 16mhz needs to be buffered like it is now, then the chip needs some series resistors... The image is stable and clear with my bodge capacitor on the board... before it was a bit jumpy and horizontal noise stuff like shown in my video.

[Smonson]

This is a bad fix..

But it solves my problem.. Where ever that 16MHz is going (middle right pin of U2) it needs 100R in there..

Hooray! Glad you got it working! And you already found and solved a problem - that's seriously impressive. I always knew the ribbon cable was not good for propagating signals, but it hasn't caused a problem on my machine.

I'll add the suggested series resistors and cap to the board design for the next revision.

[exxos]

Hooray! Glad you got it working! And you already found and solved a problem - that's seriously impressive. I always knew the ribbon cable was not good for propagating signals, but it hasn't caused a problem on my machine.

I'll add the suggested series resistors and cap to the board design for the next revision.

I forgot to mention Vsync seems to be missing on pin 4.. Don't know why, but I scope dout pin 38? on the GLUE and Vsync was there, so soldered onto a via, and everything sprang to life!

So aside from the crappy 32MHz gen on the ST, would your board work fine with the MB 32MHz if it was cleaned up ?

[troed]

So aside from the crappy 32MHz gen on the ST, would your board work fine with the MB 32MHz if it was cleaned up ?

My FPGA is programmed with code that accepts an external clock (with a patch wire) so I was planning on testing it - using my GAL to clean up the clock. I've had no issues clocking the GAL with the MB clock so that should work just fine.

You might be able to test it quicker than me though since I'm leaving for a week. The FPGA firmware for it already exists.

(I'm thinking I will install the FPGA back into my 520ST and figure out the resets I have there instead of my doubleST. Then I'm much closer to what you and Smonson have working)

edit: Btw, did you add _both_ 100R and the cap to clk_out or just the cap?

[exxos]

edit: Btw, did you add _both_ 100R and the cap to clk_out or just the cap?

I've not added the resistor as would have to cut a track, and didn't want to risk "slipping" and trashing the board when I only just had it

32MHz.. I was just thinking of removing the osc and feeding it that way ?

[troed]

32MHz.. I was just thinking of removing the osc and feeding it that way ?

Might work ("5V" vs 3.3V but the MB 32MHz is already weird so maybe it works). My version uses one of the external pins into the 5V->3.3V buffers and from there a patch wire to the FPGA clk_in. But that's of course because I have a "proper" 5V clock from the GAL as source.

[Smonson]

So aside from the crappy 32MHz gen on the ST, would your board work fine with the MB 32MHz if it was cleaned up ?

Yup, it only requires a 3.3v clock supplied on pin 17 (and the oscillator on the FPGA board disconnected). Alternatively you could supply the clock to pin 88 of the FPGA board and I'll create another version of the firmware that ignores the existing oscillator input.

The 5 spare pins in the vsync connector pass through a 5-to-3.3v buffer which then go on to the FPGA board. E.g. the centre pin beside vsync goes to FPGA pin 21, which can be bridged across to 17 or wherever. Troed did it this way.

[exxos]

The 5 spare pins in the vsync connector pass through a 5-to-3.3v buffer which then go on to the FPGA board. E.g. the centre pin beside vsync goes to FPGA pin 21, which can be bridged across to 17 or wherever. Troed did it this way.

Ah, would make life easier if theres a 5>3.3 translate already to the FPGA which I can simply wire into..

Will try and do that monday..

[Smonson]

I can't guarantee that the buffer will be fast enough for the 32MHz clock though, I recommend checking it on a scope before depending on it.