SX48 & USB SX-Key?
threepointone
Posts: 10
So, I just got my USB SX-key a few days ago. Good news: the debug finally works (my old serial one was messed up and wouldn't debug anything) on my SX-tech board (uses SX-28 DIPs). However, I also tried debugging an old working program on my sx-48 proto oard, and it started saying some weird things like "SX-Key not found on COM4". At some point, it refused to program anything anymore, failing with a "programming failed" message, even with the old serial SX-Key. Is there something I've done wrong? Is the new SX-key supposed to work with the SX-48s?
BTW, there is NO oscillator in this SX-48 design. It uses the slow internal oscillator @ 1Mhz.
DEVICE········· SX48, OSC1MHZ
IRC_CAL··IRC_SLOW
FREQ··········· 1_000_000
I also used the "read" function in the debug window to poke around, and the SX48 is reading all FFs. The SX48 appears to be fried, but what's a bigger concern of mine is exactly why--did I do something wrong, is it some sort of incompatibility, or what? I have a circuit connected to the SX-48, of course; however, unless I'm mistaken, the programming pins are separate from the I/O pins. There isn't anything electrically nasty connected to the circuit at all--just a couple of pushbuttons and a couple of I2C devices.
The USB SX-Key is working fine--I retested it with the SX-tech board and it still does the debugging fine.
BTW, I'm also getting some intermittent "chip connection failed" errors, but they don't seem to be causing that much of a problem.
BTW, there is NO oscillator in this SX-48 design. It uses the slow internal oscillator @ 1Mhz.
DEVICE········· SX48, OSC1MHZ
IRC_CAL··IRC_SLOW
FREQ··········· 1_000_000
I also used the "read" function in the debug window to poke around, and the SX48 is reading all FFs. The SX48 appears to be fried, but what's a bigger concern of mine is exactly why--did I do something wrong, is it some sort of incompatibility, or what? I have a circuit connected to the SX-48, of course; however, unless I'm mistaken, the programming pins are separate from the I/O pins. There isn't anything electrically nasty connected to the circuit at all--just a couple of pushbuttons and a couple of I2C devices.
The USB SX-Key is working fine--I retested it with the SX-tech board and it still does the debugging fine.
BTW, I'm also getting some intermittent "chip connection failed" errors, but they don't seem to be causing that much of a problem.
Comments
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
clarification again: the SX28 (SX tech board) debugged, programs, and works fine, but for some reason after i tried debugging the sx48 proto board, the SX basically got fried. The SX key version doesn't have anything to do with it.
Post Edited (threepointone) : 5/11/2008 3:37:32 PM GMT
2.66 MHz is the slowest it can generate.
I don't know if that is causing you troubles or not.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Did you know that 111,111,111 multiplied by 111,111,111 equals 12345678987654321 ?
www.iElectronicDesigns.com
·
For the next revision (I know it's still beta) there probably should be something that'll prevent debug from working if the clock is too slow.
To slow down the SX to a speed of 1 MHz, you might concider using a 4 MHz clock but turn off TURBO mode. This is not exactly the timing of an SX in TURBO mode with a 1 MHz cock, but comes pretty close.
The final IDE version should give a warning when clocks below minimum are seleced, and I'm pretty sure, Peter will implement such goodie.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
BTW, is there any suggested order in which to plug the SX-Key 4-pin header, SX-key USB port, target board, and power to the board? I'm wondering if plugging in everything in some funny order could have done something.
I'll just up the clock speed to the 4Mhz internal oscillator--I had it on the lowest internal oscillator since I didn't really need speed in my application, and·i thought it'd reduce current draw (and maybe emi/rfi)·a bit
Thanks!
ps: also, I was thinking--is it possible that the code protection bit was accidentally enabled due to some programming glitch? if so, how would I be able to tell? Is there some command to completely wipe code-protected memory clean (without reading it--IIRC some PICs can do that)?
Post Edited (threepointone) : 5/18/2008 3:03:17 PM GMT
well, your initial post in this thread insprired me to post the other ESD-related one. As your SX-Key USB seems to operate with other targets, it is most likely that you have "fried" the SX48.
Regarding the order to plug in things:
The on-board components of the SX-Key USB are powered from the USB port. As soon as you connect the SX-Key USB to any USB port, the OS performs the typical initializtion steps to make a new "virtual" COM port available. The SX-Key IDE scans the available COM ports only at start-up. IOW, you should apply power to the SX-Key USB by connecting it to a USB port prior to launching the IDE so that the IDE can find this COM port. This is at least true when you use the SX-Key USB together with the IDE the very first time, where you need to enter the "Run - Configure" dialog in order to select the COM port.
Next, I think it is fine to connect the SX-Key USB to the target board's 4-pin header, where actually only three pins OSC1, OSC2, and Vss are fed through to the SX-Key USB. IOW, the target system can never be powered from the USB port but only from a separate power supply with a voltage rating of 5 V, or lower. Note that this is the most critical operation ESD-wise, so it is important to make sure that the USB ground potential of the SX-Key (which is directly connected to the Vss pin in the target 4-pin header), YOU, and the target's Vss potential are on the same electrical level.
As final step, I would apply power to the target board.
Regarding the clock speed, you are right, the lower the clock speed is, the lower the power consumption (and EMI/RFI) will be. So, when clock precision is not an issue, it is fine to use the internal clock generator, even down to 128 kHz. On the other hand, the debugger can't work together with the internal clock generator. It will always generate its own clock signal and feed it into the target, where the lowest can be 2.66 MHz.
Regarding code protection:
When an SX is programmed with code protection on, you may read back the program memory but the returned data is scrambled. The IDE's "Run-Device" dialog allows you to compare (Verify) the contents of an SX program memory against what the last assembly result was. When you try to verify a code-protected SX, the verify will definitely fail.
You can always re-use a code-protected SX by simply re-programming it with the DEVICE PROTECT option off. There is no need for wiping program memory before, this will be automatically handled by the IDE during the next programming session.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G