Going from Internal to External Oscillator

Clint

Is there anything special I need to do in the programming of the SX when switching from the internal 4mhz oscillator to an external 50mhz oscillator? Do I need to change the "DEVICE" directive or the "FREQ" directive or both or neither?

I am reading an incremental encoder with an interrupt routine and found that sometimes if I move the encoder too fast, the SX fails to count appropriately.

This is what my SX/B code looks like at the beginning.

DEVICE          SX28, OSC4MHZ, TURBO, STACKX, OPTIONX, PROTECT, BOR22
FREQ            4_000_000

And I also have

OPTION = $88                                  'interrupt, no prescaler

Thanks for any input

Bean

Change OSC4MHZ to OSCHS2 and change "FREQ 4_000_000" to "FREQ 50_000_000".

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"A government big enough to give you everything you want, is big enough to take away everything you·have."·· Thomas Jefferson

"It is our choices, Harry, that show what we truly are, far more than our abilities."·Dumbledore from Harry Potter

www.iElectronicDesigns.com

·

Clint

Thank you Bean.

I am using the SX Tech board and SXKey for developing and programming my project. Do I just put the oscillator in the socket and program as usual or is there something special I need to do?

JonnyMac

If you have an SX-Key (versus the Blitz) you can actually click on the Run button and the key will generate the clock for you -- this is useful for testing.

PJMonty

Clint,

Are you using an external oscillator or a resonator?

Thanks,
PeterM

Timothy D. Swieter

The external resonator/crystal should not be in the socket when you try to program that device. You should remove the crystal and then plug in the programmer to program. As JonnyMac was saying, if you have an SX-Key you can have that device clock your project for debugging purposes. When you want to run the project stand alone, you can remove the programmer and replace the resonator/crystal in the socket.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter, E.I.

www.brilldea.com·- Prop Blade, LED Painter, RGB LEDs, uOLED-IOC
www.sxmicro.com - a blog·exploring the SX micro
www.tdswieter.com

T&E Engineer

I don't think it will hurt to have the crystal/resonator installed while programming the SX. However, if you choose DEBUG program it, you can and probably will damage the SX-Key. This is at least the case for the Serial port SX-Keys.

Has this been fixed on the new USB SX-Keys? I just bought one last week.

Guenther Daubach

Hey all,

using an SX-Key (no matter if serial or USB) for debugging together with an XTAL, resonator, or clock generator installed should not damage the SX-Key at all because both types have resistors installed in series with the OSC1 and OSC2 pins for protection.

Nevertheless, debugging will not work in most cases when an XTAL, resonator, or clock generator is installed because the SX-Key takes control over the OSC1 and OSC2 pins for communication and clocking during a debugging session. So any external component attached to the OSC1 or OSC2 may interfer this activity. When after a "Run-Debug" the debugger comes up with a "Sleeping" or "Running" state, it is most likely that an extra component is still attached to the OSC1 or OSC2 pins of the SX device, so you better double-check.

Also be aware, that the SX-Key/Blitz applies a voltage of about 12V to the OSC1 pin while programming the chip. Ceramic resonators, and XTALS are usually not harmed by this voltage, where clock generators might, so you better disconnected them from the OSC1 pin before programming the SX.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Flash

Gunther,
I am having a problem similar to what you describe; when I run Debug, it comes up either Sleeping (most of the time) or the display says "Running" but it is not. (No scope trace at the output pin.)
In both cases the only working butting is Quit. If I then 'Debug Again' the debugger comes up ok, and pressing Run works, but Walk immediately goes to Sleep. No encumbrances on the OSC pins.
Code is a minor modification of the SX/B sample, 'Blink 1', that uses PAUSEUS commands. Any pearls of wisdom are welcome. Thanks

Zoot

99% of the time I have had this problem, it was either dirty connections between the SX-Key and the prog. port on my board, or using a long header cable, etc.

My experience has been that with a dirty connection it is always possible to *program* the chip, but not debug (the debug features run at a very high clock rate). In some cases just cleaning pins on my programming port on the board did the trick.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Guenther Daubach

Flash,

recently, I ended in a "Sleeping" state with the debugger with no resonator installed. Finally, I noticed that there was a 10 kOhm resistor installed in the circuit between the OSC pins. After removing it, debugging worked as expected.

In general, when the debugger is active, the SX-Key monitors the target's OSC2 pin for signal edges generated with different timing, depending on wether the target is running, or in idle mode (for single-stepping), or no signal edges at all when the device is sleeping. IOW, when the Debugger displays "Sleeping", this means that the SX-Key does not "see" any pulses on the target's OSC2 pin. Reasons may be that the target is really sleeping, that the connection to the target's OSC2 pin is broken, or that some load on the OSC2 pin pulls down the signal.

Another reason may be that you try to debug a chip that has been programmed with no debug code. This may be the case when you program the chip with "Pun -Program", and then launch the debugger with "Run - Debug (reenter)". In this case, the target SX does not "know" about debugging, and thus does not generate status signals on OSC2 at all, making the SX-Key "believe" the target is sleeping.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G