Repeating of that tiny window was very slow... nearly 20ms between each sample-output. Much too slow to see in B-Timing on the 'scope.

That's been fixed!

(The picture's not-so-good, it's a screenshot from a video taken in non-ideal lighting conditions...)

Scrolling through the samples, it appears that the upper channel is the clock. I counted ~25 edges the first-go. Did some math, and determined that the sample-rate is *durn near* the clock-rate. So that might account for the fact that some clock-pulses *appear* to be aperiodic... The clock rate is too high for my sampling-rate.

So I bumped up the sampling rate to 20MHz just to check and now I'm counting ~30 edges that appear quite a bit more periodic. (And I'm running an AVR rated for 8MHz at 20MHz, woot!).

side-note: my 'scope is rated at 20MHz... in "digital mode" that's reduced dramatically. In analog-mode I've viewed *repeating* logic-transitions at upwards of 100MHz. So, even though the clock-rate of this data-burst is at my 'scope's rated limit, I should still be able to see the data in analog-mode due to the fast-repeating of this "logic analyzer".

The fast-repeat Fix:

Been digging even deeper into the code... As I said before, this project was collecting dust for nearly a year, so it's taking some time to refresh my memory.

The fix for slow-repeating was much easier than I expected; I completely forgot that I had set-up an SDRAM-Refresh each time the sample is output... two, actually. One before starting, and another after finishing. NEITHER are necessary, as I've experimentally verified that this SDRAM is reliable even when refreshed only once every *10 seconds*. Further, the very act of refreshing the image on the LCD display (as happens periodically, even when repeating just a window) *causes* the SDRAM to be refreshed, as well. (Opening a page and closing it acts as a refresh on that page; displaying on the LCD cycles through all the pages, thus the entire SDRAM gets refreshed).

The Future:

I wasn't planning on doing this any time soon, but it appears I'll have to if I want to read this data-burst correctly:

The original idea with "Free-Running" SDRAM was that once it's free-running, it no longer needs MCU control... So, then, there's no reason it couldn't run at its full-speed (133MHz=133MS/s).

It *will* require some hardware modification, and a bit of thinking...

I've already pondered it quite a bit in the past. Running the SDRAM at, say, 100MHz, and the AVR at, say, 10MHz means that (some of) the commands sent to the SDRAM have to be *one-shot*... Most commands can be repeated back-to-back. E.G. a READ command at a specific address would be written by the AVR to the SDRAM's Command/Address lines for one AVR clock-cycle, then the SDRAM would receive that same READ command 10 times. This is fine, since each consecutive read at the same address would just cause it to repeat the same data. Similar is true for WRITE. (Actually, that's been a nice factor with really early tests, as it meant timing needn't be precise and no latches are necessary). BUT. Some commands *cannot* be repeated like this... I can't recall the exact ones, but "Precharge" "Activate" and "Load Configuration Register" come to mind.

So, for these, I'll have to have a one-shot circuit... at the very-least on the Chip-Select line. I'm imagining a shift-register and a couple gates running at the SDRAM speed.

The original design-plans for this one-shot were for sdramThing1.0 and 2.0, which didn't have a "side-kick." Basically all they did was continuously repeat the entire contents of the SDRAM, as loaded, slowly, by the AVR at boot. (E.G. a non-changing LCD image).

The Side-Kick added the ability to sample/repeat arbitrarily, which makes it great as a logic-analyzer, but the wiring-method had to change, and in-so-doing also required a new scheme for sending commands... It relies heavily on timing. E.G. a "READ" command is issued, then exactly three clock-cycles later (the CAS latency) the data is read... on the same pins that issued the read-command. So, this will get even more complicated with one-shot circuitry. Also, there's quite a bit of precision-timing with the Data-Mask pins which can be used to inhibit writing/reading at certain locations...

Another possibility is to run the SDRAM at the MCU clock-frequency for loading, etc. then switch the SDRAM's clock over to the higher frequency for free-running. It's plausible.

ddrThing:

There've been thoughts about switching over to DDR, as it's becoming increasingly-available in junk-piles, and has a few other benefits to a project like this. But, it's also quite a bit more complex... I mention it, here, in response to the possibility of clock-switching for sdramThing(4.0?)... Clock-switching might not work with DDR, as (I think) there's an internal clock that's synchronized with a steady external clock. So, if I'm thinking toward the future, then I might wipe the clock-switching idea...

At this point, it's moot. I don't have any 100MHz clock sources :)