In SX Microcontrollers, SX/B Compiler and SX-Key Tool, g_daubach wrote:

threepointone,

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.

---------- End of Message ----------


You can view the post on-line at:
http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=267870#m268997

Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com

The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2008 (http://www.dotNetBB.com)