Project: HDMI/DVI out for STFM

[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)

[exxos]

This is on a stock machine - the 520.

Ah, so you have the reset problem with your doubleST AND a stock 520 ?

[troed]

This is on a stock machine - the 520.

Ah, so you have the reset problem with your doubleST AND a stock 520 ?

Yes. On the 520 the clocks are generated by the FPGA, using the Shifter socket clock_out for the rest of the ICs.

On the doubleST the clocks are generated by the GAL, for all ICs including the FPGA.

... so I'm really not sure it's the clocks since I see no overlapping path, but I have no other idea. Both machines are rock solid with original Shifters.

It's not: /BERR, /HALT, VCC (!), /DTACK, /MONOMON.

The LA shows normal activity AFAIK right up until RESET. I have no idea how any component in the Shifter socket can cause this. Even if the FPGA is somehow malfunctioning, how would it induce spontaneous resets?

Screen Shot 2018-09-09 at 19.43.50.png

MP4 video: https://troed.ddns.net/f/b9c4521ba36a499aadd1/

[exxos]

Very odd...

What board exactly are you using ? I can try and find same board here to try out..

[troed]

Very odd...

What board exactly are you using ? I can try and find same board here to try out..

C070243 REV.I (520STM)

Even if there's something different with my FPGA prototype compared to yours I still don't understand how ...

[Smonson]

To eliminate the possibility of power supply issues, could you try running the machine with the stock shifter installed, but with the FPGA board connected to just +5, ground, and vysnc? If possible, from somewhere connected close to the shifter socket. Then it should run through video generation just by itself and possibly introduce power supply or ground noise.