Project: HDMI/DVI out for STFM

[Smonson]

...or maybe the 32MHz clock could just be running at 3.3v in the first place, by transplanting the crystal?

[poobah]

...or maybe the 32MHz clock could just be running at 3.3v in the first place, by transplanting the crystal?

Run it through a spare lane on your level shifters.

[Smonson]

Yeah but I thought the whole point was to use a proper clock driver

[exxos]

Now I found some 32.084988MHz oscs.. the bottom pcb has loads of room ?, so if enough room for a "DIP 14" osc then just bung one of those in your board.. then its the best frequency to use on all machines... but of course these are 5V... I suppose its either run it via the buffer, or they *might* run on 3.3V.. would have to check when they arrive...

[Smonson]

Worth a try. If the osc packages aren't too big then I can always put one in the cut-out area, since it's optional.

[troed]

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..

(I've now reverted my FPGA to "stock" with the idea that if I solve what causes the resets on my 520 that might help in finding out why they happen on my doubleST)

So my first guess is to replicate your fix above, so I added a small cap. Didn't make a difference though. Just for reference, what value did you use?

(Now I'll cut the trace and add some resistance instead)

[exxos]

So my first guess is to replicate your fix above, so I added a small cap. Didn't make a difference though. Just for reference, what value did you use?

I think it was 50pf.

The ringing on the line likely causing some glitches in the clock causing the machine to lock up .

[troed]

Shot a video just to show what I mean with "spontaneous resets". This is without touching anything. Disregard the failed video mode at some resets, that's not relevant (unless it indicates something about what happens, I don't know) - it's the resets themselves that are of interest.

https://troed.ddns.net/f/4c164bc45c284ef0888b/

This is from a 520ST with a picoPSU and the stock FPGA with its own 32.000MHz crystal. There's some pF on the 16MHz clock out - no difference with or without.

I have what seems to be the same resets, although seemingly much more often, when I run it in my doubleST. There a GAL produce all clocks, incl. the one for the FPGA. The FPGA clock out is _not_ used - and those GAL-generated clocks are stable when using a stock Shifter instead of the FPGA.

So now I'm going to debug this issue on the 520 instead ... I'm still not sure why the ST always resets instead of crashes/bombs etc. I think that's a bit surprising.

[exxos]

So now I'm going to debug this issue on the 520 instead ... I'm still not sure why the ST always resets instead of crashes/bombs etc. I think that's a bit surprising.

I can't get anything to show on the video, either on the page or downloading it..

May be a good idea to scope out the clocks and see what you have on them all.. The capacitor actually makings the ringing worse, but oddly works on my machine.. So a resistors in series with the clocks is a much better idea..

Probably is a good idea to try on a stock machine as well.. I would assume it will work fine (as it does on my STFM).

[troed]

Probably is a good idea to try on a stock machine as well.. I would assume it will work fine (as it does on my STFM).

This is on a stock machine - the 520.

(The video should be a standard .mov - but I'll recode to mp4 container as well)