Uzebox burn-in tester

Use this forum to share and discuss Uzebox games and demos.
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox burn-in tester

Post by Jubatian »

Some overclocking reports on an XMega: ATXMega256A3U-AU.

Normally this chip is rated for 32MHz at 3.3 Volts. I created a small application running XMBurner on it, reporting in terminal through a serial line. It is quite easy to overclock the XMegas as they contain a PLL with which you can set up an arbitrary multiplier for an input clock.

As an important note currently XMBurner has most instructions covered except for multiplications, so still multiplications might fail at these increased frequencies (but at least an unsigned multiply by four definitely works since it is used for CRC checks to address the CRC table). Otherwise the full ROM and RAM is tested, and I also had SPI flash chips connected in the design running at maximum possible SPI speed (also tested).

So I started to experiment with it.

Staying at 3.3 Volts I could throttle up the frequency to 64MHz, and XMBurner reported everything fine (millions of test cycles and no errors detected).

At 72MHz the CRC test started to report CRC errors. This could be of two main reasons: One is that the (e)lpm instruction might no longer be able to read the ROM reliably, the other might be that the multiply-by-four instruction required to address the CRC table starts to fail. I suspect the latter.

At 64MHz I started to throttle down the voltage of the CPU. It kept running stable down to 3.00 Volts (several millions of test cycles with no errors), below that XMBurner started to report occasional faults of the NEG instruction and coming out of reset was no longer reliable.

So seemingly this particular XMega chip runs fairly well even at double its rated frequency! Of course just at room temperature, anyway, it could be interesting for someone interested in messing around with video signals (for example 50MHz would work well for generating standard VGA).
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzebox burn-in tester

Post by Artcfox »

Wow! That is quite the overclock! Does it make a difference if you use a power brick versus battery power on how much you can overclock?
User avatar
Jubatian
Posts: 1564
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Uzebox burn-in tester

Post by Jubatian »

Artcfox wrote: Fri Oct 20, 2017 1:45 pm Wow! That is quite the overclock! Does it make a difference if you use a power brick versus battery power on how much you can overclock?
Should it? I experienced that the XMega when running at higher frequencies will draw more current. So if your power source can not supply it and the voltage drops, it can have effect (at 32MHz the XMega ran happily even at 2 Volts, I couldn't get XMburner detecting anything before I started overclocking, so yes, if your power supply is unable to give it a steady 3.3 Volts, then it will become unstable while at 32MHz it is much less likely).

I did an oversight though: I don't think the multiplication instruction is the culprit at 72MHz, rather more possibly the (e)lpm instruction fails to perform a correct read. The addressing definitely works (18 bit increments for 256K ROM), also the CRC algorithm, these are tested in parallel with alternate algorithms, so anything amiss would be detected on the spot. However every ROM cell is read only once before feeding it to the two CRC algorithms (so obviously if the read itself fails, that will only be detected by the CRC).

I see other people having similar results with XMegas, I guess running one at ~43MHz (12x NTSC Colorburst) would be quite safe for gaming (this is 1.5 times the frequency of Uzebox, easier to port things, and the 3 cycle "ld" instructions of the XMega would still take the same amount of time like the 2 cycle corresponding instructions in the ATMega). Anyway, this is not that topic, it was just an interesting experiment to see how an XMega running the self-test library reacts to overclocking.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzebox burn-in tester

Post by Artcfox »

Jubatian wrote: Fri Oct 20, 2017 6:52 pm
Artcfox wrote: Fri Oct 20, 2017 1:45 pm Wow! That is quite the overclock! Does it make a difference if you use a power brick versus battery power on how much you can overclock?
Should it? I experienced that the XMega when running at higher frequencies will draw more current. So if your power source can not supply it and the voltage drops, it can have effect (at 32MHz the XMega ran happily even at 2 Volts, I couldn't get XMburner detecting anything before I started overclocking, so yes, if your power supply is unable to give it a steady 3.3 Volts, then it will become unstable while at 32MHz it is much less likely).
I'm not sure if that would make a difference for you, but when I overclocked several ATmega328P's I couldn't get them to run at 30MHz from a 2A switched mode 5V power adapter (with 10uF and 100uF filtering caps), but they run perfectly at 30MHz from three AA cells (4.5V) and continue to run perfectly as the batteries drain all the way down to 3.0V (which is below the forward voltage of the green/blue LEDs, so they stop lighting up, but the AVR seems to still function fine). I can also run them just fine at 30MHz using a 3.7V lipo.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox burn-in tester

Post by CunningFellow »

Flash will be most likely to fail.

That is why chips above 30 or 40 Mhz have settings for flash wait states and flash read ahead buffers and cache.

The reason battery would have been working better in Artcfoxs case is noise. When your on the edge, even small levels of noise making it inside the chip can make a difference.

a 10uf and a 100uf will not have gotten rid of the high freq noise from a switchmode. Having and inductor in-line and then also adding a few more decades down to be sure (1uf + 0.1uf in ceramics).

A way to confirm this would be to use a linear regulator with good PSRR bewteen the switchmode and the AVR.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Uzebox burn-in tester

Post by Artcfox »

CunningFellow wrote: Fri Oct 20, 2017 9:00 pm Flash will be most likely to fail.

That is why chips above 30 or 40 Mhz have settings for flash wait states and flash read ahead buffers and cache.

The reason battery would have been working better in Artcfoxs case is noise. When your on the edge, even small levels of noise making it inside the chip can make a difference.

a 10uf and a 100uf will not have gotten rid of the high freq noise from a switchmode. Having and inductor in-line and then also adding a few more decades down to be sure (1uf + 0.1uf in ceramics).

A way to confirm this would be to use a linear regulator with good PSRR bewteen the switchmode and the AVR.
Good to know!

Oh, I also had 0.1uF ceramic caps in all the recommended spots and a 4.7nF cap between reset and gnd, plus the diode and 10K resistor between pin 1 and VCC that the app notes tell you to. I figured that stuff was a given, I was just talking about "above and beyond what the dataset says to include" to try to filter the power. The only thing I didn't have was a 1uF ceramic.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Uzebox burn-in tester

Post by CunningFellow »

Try making the switchmode 8v and then put a 7805 in between (with all its usual caps) and see if that makes a difference.
Post Reply