'New' 28X2 - 64 Mhz at 5v - is this real ?

Buzby

Senior Member
#1
After reading the new X2 pdf, it looks like the 'new' 28X2 can run at 64Mhz when powered at 5v ( as opposed to the 'old' 28X2-3v that I bought !. )

Is is correct ?.

If so, I can throw away my level translators and drive my 5v LCD directly, whilst still running the precision ( sort of ) timing at 64Mhz.

Thanks.
 

hippy

Technical Support
Staff member
#2
That's correct. EM64 supported on the new 28X2 and 40X2, so 64MHz with a 16MHz resonator / crystal ( as per the 28X2-3V ).
 

Buzby

Senior Member
#3
Great stuff !

Just as an aside, with no practical use in mind, fully aware that serial coms and every other timing critical stuff goes out the window, what is the fastest you could clock a PICAXE ?.
 

hippy

Technical Support
Staff member
#4
Hard to say, above 64MHz is out of spec but anecdotal evidence suggests +20% to +25% over-clocking usually works, around +50% things can start to go wrong. One problem is usually lack of specific or up to date information and it varies depending on chip model.

I've seen reports that PLL's can clip over-clocking capabilities but have also seen it claimed that an 18F25K20 (28X2-3V) can run at 100MHz, 25MHz crystal+PLL (+50%). It seems you usually do better with PLL off than on, and that's probably with an oscillator module rather than a crystal.

The new 28X2 has a PLLEN bit but I'm not sure if that can be used to turn off the PLL when an external oscillator mode is selected. If not you're probably aiming for ...

20MHz -> 80MHz
24MHz -> 96MHz
25MHz -> 100MHz

The only real way is to try it, but then you cannot easily test everything but it may be 'good enough' for the task in hand. Using high-speed serial you should be able to get comon baud rates but PAUSE commmands etc will need recalculating.

A quick test with EM32 toggling a LED every second, simply moved to a 25MHz oscillator module shows the LED toggling every 0.65 seconds, 0.7Hz. Then it slows right down, 4 second toggling - falls-back to fail-safe clock ? On breadboard so could be a loose connection.
 
#5
Take note that even ambient temperature changes can change the frequency that such overclocking tricks will reliably work at. But it sure is fun to play with them. Also, results may (will) vary from chip to chip.
 

hippy

Technical Support
Staff member
#6
100MHz - Fastest PICAXE ever ?

Seems it was a breadboard problem. Put the 25MHz oscillator module on vero-board with 100nF cap and flying leads and it's now much better, still running at '100MHz' after an hour; failed after a couple of minutes in post #4. Using new 28X2 ( 18F25K22) at 5V

Not everything is perfect, but haven't got the high-spec equipment to be sure it's not just sampling error ...

HSEROUT 1, %110 : HSEROUT 0,("U") - Puts out 6 Mbaud but bit times aren't consistent. Similarly with lower PC-ish baud rates but look to be within acceptable tolerances.

HSPISETUP SPIMODE11, SPIMEDIUM : HSPIOUT("U") - Puts out 6MHz clocking, but same inconsistencies as with high-speed serial. SPISLOW is 1.6MHz, again with some inconsistencies. HSPIFAST doesn't work, just one clock pulse output.

PWMOUT C.1,255,511 - Puts out 97.5kHz

So all-in; success of sorts, and amazing success considering that's +56% over-clocking !!!

I'm amazed it even worked at all at that extreme. You can always drop back to internal oscillator to handle HSEROUT or HSPIOUT. As it does that on program download, no problems with downloading with oscillator module in circuit. Not notable current increase ( except 30mA for the oscillator module ), 28X2 doesn't seem to be getting hotter, as cool as normal.

On results so far I'd be happy to use in in a home project where I felt 'the need for speed' and application wasn't 'business critical'.

For the 'how fast does a PICAXE go' crowd ... basic 'simple instruction' time of about 17us.
 

hippy

Technical Support
Staff member
#7
Today's test was for baud rates; seems okay at 9600 through 115200 to/from a PC via AXE027 over a number of hours. Baud rate constants included in attached program.

Those tests also work down to 3V3 but not much below. Will probably depend on the oscillator module voltage requirements.

Next step would be to find a 27MHz oscillator module and see if 108MHz works; +70% over-clocking. That's probably a stretch too far, but who knows.
 

Attachments

Last edited:

hippy

Technical Support
Staff member
#8
I previously suggested, for an AXE091 development board, connecting the oscillator module to pin 14 of the 40X2 socket to override the 28X2 on-board resonator. That may not be a good idea as that links to OSCOUT which is an output. Do that entirely at your own risk and be prepared for the PICAXE to be damaged. Running over 64MHz won't be covered by Rev-Ed warranties.
 
#10
Did you get around to test 108MHz? Not that it is very important but I'm curious :) I have had my chip spinning at 80MHz for about half an hour now on a breadboard with no problems. I am using setfreq em40 and a 20MHz oscillator. The pause command is then divided by 10. ( pause 10 equals 1 ms )

low b.7
high b.7

above code gives 23us low :).

low b.7
pause 1
high b.7

above code is 140us low, indicating that the pause command takes 17us and the high command takes 23us.

Oh, the things we do for fun.....
 
#11
Hippy, I am also interested in this...

Is it also possible to run your original DMX code (with specific timing changes) at 100mhz instead of 64mhz on a 28x2 ?

Thanks in advance
 
#15
When overclocking to above 108MHz, you might need to start increasing the power supply voltage - up to 5.4V - and possibly add a heatsink and fan!
 

hippy

Technical Support
Staff member
#16
@ bobmcnobby2 : Yes, that looks like it should work. It would all depend on comms being stable and being able to find a baud rate divisor which gave 250k baud.

@ nick12ab : I didn't notice any heat increase using 100MHz at 5V so would expect the same at 108MHz. It's worth playing with the voltage though especially if still within spec. I'd probably risk up to the absolute maximum at least for short periods while experimenting.
 
#17
Overclock attempts

This is the code:
Code:
#no_table
#picaxe 40x2
#terminal 2400
main:
    serout A.4,N2400_8,("5 ")
    pause 1000
    serout A.4,N2400_8,("4 ")
    pause 1000
    serout A.4,N2400_8,("3 ")
    pause 1000
    serout A.4,N2400_8,("2 ")
    pause 1000
    serout A.4,N2400_8,("1 ")
    pause 1000
    serout A.4,N2400_8,("START ",cr,lf)
    setfreq em64
    low A.4
    pause 500
    do
        serout A.4,N9600_64,("PICAXE ")
        pause 500
    loop
The countdown is to allow the supply capacitors to fill up completely before attempting to apply the overclock. Then, after 'start', the setting in the terminal is changed to 19200.

The power supply is a switching regulator using this chip and the feedback resistor is replaced with a potentiometer to adjust the voltage.

I've tried 128MHZ (32MHz)at voltages up to 6.5V and I can't get a stable overclock! The next crystal down I have is 24MHz which works at 5V anyway.

Attempt 1

Board: Serial GLCD Module (without GLCD) and 'docking station' board with power supply
Crystal: 32MHz
PICAXE: PICAXE-40X2 universal voltage version
Load capacitors: 15pF on pin 14
Voltage: 6.5V

overclock1.jpg

Unstable

Attempt 2


Board: Serial GLCD Module (without GLCD) and 'docking station' board with power supply
Crystal: 32MHz
PICAXE: PICAXE-40X2 universal voltage version
Load capacitors: Both pins
Voltage: 6.5V

overclock2.jpg

Nothing

More will come very soon...
 
#18
Also tried no load capacitors - it just ran off its internal oscillator.

The PICAXE survived.

On a side note, this PICAXE could run off its internal oscillator sending the text to the terminal down to just under 2V, at which point all the data was corrupted.
 

Attachments

Last edited:

hippy

Technical Support
Staff member
#19
Better results may be obtained using a crystal oscillator module or frequency generator. That way you don't have to worry about crystal type, whether the oscillator circuit is oscillating, loading nor what the ideal pF caps may be, and stray capacitance will be less of a problem.

I'd also start with a simple DO-TOGGLE-LOOP and a scope to see if things are running at the expected speed, scaled up from 8MHz.

PWMOUT and HSEROUT 0,("U") with 250kHz or 250k baud are handy as they are power-of-2 divisions of 1MHz so scaled signals are easier to check and won't be pushing internal division circuits to their max.
 
#20
As I've found the output waveforms of clock oscillators to be (often) less than pretty, I'd suggest a high-speed Schmitt buffer between the osc and the PICAXE. That might improve the clocking waveform enough to reach a world record PICAXE over-clock speed.

Remember, a clean clock means a happy micro.

Also, careful, (and short,) wiring connections from various parts of the circuit to others will make a difference at very high over-clock freqs. A good ground plane will also help. Such a circuit will never run anywhere near its fastest unless full RF design considerations are incorporated.

I'd suggest that a carefully done bd layout with fully implemented good design techniques (clean clock, rock solid power supply, soldered in chip, (No sockets!) good ground plane, careful trace layout, additional chip supply filtering, etc) could bring 'some' 64MHz chips up to 120 MHz reliable operation. As for heating, if the chip doesn't get unreasonably hot, some heating may make it run faster by reducing the internal junction drops.

It would be fun to take the time to try. Too bad I have no free time these days. :(
 
Last edited:
#21
An update on the PICAXE I tried to overclock to 128MHz at 6.5V - it no longer functions on the Serial GLCD Module board properly - a new one does.

To test it, I made all the pins on port B high and after measuring the voltages, all but B.7 measured 0.22V in relation to 0v and around -0.18V in relation to 5V. The PICAXE didn't get hot. Does that mean I've just rendered those pins open drain (fixable with pull-ups) or is it something much worse?
 
#23
An update on the PICAXE I tried to overclock to 128MHz at 6.5V - it no longer functions on the Serial GLCD Module board properly - a new one does.

To test it, I made all the pins on port B high and after measuring the voltages, all but B.7 measured 0.22V in relation to 0v and around -0.18V in relation to 5V. The PICAXE didn't get hot. Does that mean I've just rendered those pins open drain (fixable with pull-ups) or is it something much worse?
Dolce et decorum est, pro Picaxe..................

e
 
#25
What results did you get when it the PICAXE was imersed in liquid nitrogen ?
None to test with. However, I believe that the DIP casing is the limiting factor in how fast heat can be sunk anyway, although with it already cooled to the liquid nitrogen temperature it may have survived. If it did work, it would be impractical to use.
 

hippy

Technical Support
Staff member
#27
The PICAXE didn't get hot. Does that mean I've just rendered those pins open drain (fixable with pull-ups) or is it something much worse?
People can likely only theorise.

High frequency switching means more heat and that could have burned something out. Faster clock rates and differing delays in circuit paths may mean the chip is receiving incorrect signals and operating in an unknown fashion so it's hard to tell what it may be doing. The outputs are push-pull so one side is probably driven by the inverse of a control line to the other. At some point slewing and latency will come into play just as it does for H-bridges and you could end up with shoot-through with both push and pull enabled at the same time; resulting in a short across +V and 0V which causes damage.

To get a better impression of what is failing you probably have to be more methodical; get it working at a lower clock speed at a low voltage with a current limited supply then increase the clock frequency and note when and how it fails. Repeat with increased voltage. When it fails to work you can back it off and repeat the test to see if it's more damaged than it was before the test.
 
#29
Some months ago I had great success running the PICAXE 28X2 (PIC18F25K22, Firmware B.3) at 64Mhz via setfreq em64 and the trusty 3-Pin 16Mhz external resonator from TechSupplies. It does indeed give things an amazing speed boost!

Unfortunately when I re-compiled my BASIC program using Version 5.4.3 of the PICAXE Programming Editor somthing strange has happened. The em64 mode no longer kicks in and it defaults back to the internal 8Mhz clock. To test that this was indeed what was happening I wrote a simple test program to flash an LED, and used some nested loops to burn time in roughly 1 second intervals (at 8Mhz). Switching between m8 and em64 no longer speeds up the program, which is strange. I rebuilt a test circuit with just the 28X2, resonator, the usual pullup/pulldown resistors and an LED and setfreq em64 still does not give a speed boost.

#picaxe 28X2
#no_data
#no_table

; Normal speed (1 second between LED flashes)
;setfreq m8

; Uber speed (1/8th of a second LED strobe!)
setfreq em64

do
; LED on
high C.7

for b1= 0 to 4
for b0 = 0 to 200
; Burn about 1 second
next
next

; LED Off
low C.7
for b1= 0 to 4
for b0 = 0 to 200
; Burn about 1 second
next
next
loop


This is very strange as everything was working just fine before and chips programmed with an older editor continue to run at 64Mhz when placed in the very same test circuits.
Although I am very much out of my depth when it comes to using pokesft I have tried to simulate a call to setfreq by attempting this little trick:

SETFREQ_EM64:
pokesfr 0xD3, 0x70
pokesfr 0x9B, 0x40
return

I did not expect it to work, and indeed it didn't :D

I've tried using my old 28X2 chips and a new batch I ordered last week. They all have the same markings and firmware version.
The test circuit was just a 1K pulldown on the programming pin, 4.7K pullup on the Reset pin, One 16Mhz resonator (sharing Ground as on would expect), and a LED+Resistor to flash signals.

So... does anyone know why I can't get em64 to work any more?, I am sure it used to work just fine and I was having such good fun.
 

srnet

Senior Member
#30
Sure the external resonator is working ?

The PICAXE will have clock failure detect set, so if you try to switch to a clock that does not work, the PIC fails back to a working condition.

Mind you I have an issue with a 28X2, the resonator appears to be working, but only works at 64Mhz, regardless of what 'em' setting I use, I wanted it to work at 64Mhz in any case, so have yet to investigate further.
 

nick12ab

Senior Member
#32
Mind you I have an issue with a 28X2, the resonator appears to be working, but only works at 64Mhz, regardless of what 'em' setting I use, I wanted it to work at 64Mhz in any case, so have yet to investigate further.
So with a normal PIC does your resonator self-change to run at 32MHz then?
 
#33
Hi folks, thanks for your replies so far.

I am giving the chip 5V DC via a 7805 regulator with the usual 100uf capacitors near the chip and on the input etc, it checks out at 5.01V DC and looks clean and smooth.
I also tried giving the chis 5V directly from an N93CX bench power supply when I ran my test circuit.

The interesting thing is that if I program up a chip and put it in a circuit board with 3 other 28X2's that are running at 64Mhz (programmed 6 months ago), the 4th one that I newly programmed (same code) fails to run at em64, the rest run just fine, even when I move them into the same socket as the one that fails. Also a newly programmed chip that just flashes an LED won't run at 64Mhz in a socket that runs one of the originals just fine at that speed. It is most strange.

The only way I can check if the resonator is running at 64Mhz is by giving it a good probe with my oscilloscope. I hope the ROGOL is up to it, it's only entry level and it's made in China (no offence intended to any Chinese engineers, I do love this scope!).
Thanks again for your help.

Did my experiment at switching to 64Mhz via pokesfr have any chance of working?, I have had to guess what to poke by reading other peoples assembly language for this PIC core so I wonder if Hippy knows the correct way of doing this.
I know only the External resonator can reliably give 16Mhz X 4 clock speed but I would guess that the internal clock can also be tweaked to run at 64Mhz (albeit unreliably and at risk or turning the chip into toast). I've got a few spare 28X2's that I am happy to sacrifice in the name of science to see if it works.:eek:
 

nick12ab

Senior Member
#34
I know only the External resonator can reliably give 16Mhz X 4 clock speed but I would guess that the internal clock can also be tweaked to run at 64Mhz (albeit unreliably and at risk or turning the chip into toast). I've got a few spare 28X2's that I am happy to sacrifice in the name of science to see if it works.:eek:
Not going to happen. See this thread: http://www.picaxeforum.co.uk/showthread.php?18570-No-M64-on-28X2

[HR][/HR]
May or may not be relevant: http://www.picaxeforum.co.uk/showth...ut-cristal-16MHz-with-em64-make-no-difference
 
Last edited:

hippy

Technical Support
Staff member
#35
Did my experiment at switching to 64Mhz via pokesfr have any chance of working?, I have had to guess what to poke by reading other peoples assembly language for this PIC core so I wonder if Hippy knows the correct way of doing this.
For EMxx I believe the only thing you need to do is switch from INTOSC to EXTOSC ( SCS<1:0> in OSCCON ). The PLL is enabled by fuse so it will then automatically run at 4 x crystal frequency, the SETFREQ EMxx doesn't set the speed only sets EXTOSC and lets the firmware know what the speed is.

Because the PLL fuse is set by default, that means you can't poke any OSCCONx registers and enable PLL for INTOSC.

Looking at the generated code for the 28X2 it really is "SETFREQ <num>", not a POKESFR so it's hard to see how any change of Programming Editor or the compilers altered anything for a chip whose firmware is the same as it always was.

Could it be you have somehow fried the internal oscillator used for the crystal ?

Two things you could try -

Try "SETFREQ EM16" or "EM32" but keep the 16MHz crystal; will still run at 64MHz ( as per above ).

Try a 4MHz crystal and see if that gives 16MHz speed for all EMxx settings.
 
#36
Thank you Mr Hippy, I shall try just that, all I needed was some suggestions to experiment with and I will come back with some results, be they success or failure. I don't think I have cooked the oscillator but stranger things have happened so let me assume they're the most likely point of failure. I will try again using a fresh one and a breadboard (no heat!). 4 other oscillators in another board I made appear to work just fine only not when I use my recently programmed chip. Let me get back to you all tomorrow as I am currently waiting in a queue at fish and chip shop (wrong type of chips).
Bye for now...
PS
If I can find my original copy of the Editor I will recompile so to see if anything changes. I think you are right that it's not the cause but again it does not hurt to test, and I am doing this hobby for the thrill of discovery.
 

nick12ab

Senior Member
#39
Not sure what you mean by that.
You were saying that the resonator is always running at the same speed regardless of 'em' setting.

I'm asking whether you can change the speed of the resonator with a native PIC.

The PICAXE just uses the external resonator with the PLL regardless of 'em' setting and for 32MHz operation a 8MHz crystal should be used instead.
 
Top