Debug problems at 3.0 Volts.
dkemppai
Posts: 315
Hi all,
Can't seem to get my SX48 to debug at 3.0 volts. SXKey is at 5 volts. The thing programs (incorreclty???), but won't run or debug at 3.0 volts.
If bump the chip to 5 volts, it program, it·debugs, and runs as normal.
At 3.0 volts, the SX-Key software won't allow me to reset the device. Can't even tell if the chip is working. The SX-Key just starts up clocking the chip, without·giving me the·option·choosing·walk, run etc. ·It just starts "Running",·and all of the buttons are greyed out.
See attached image. Can't·run the other·hardware at 5 volts, Will burn up·IC's.
Also, note of interest, with the key at 5.0 volts and the Chip at 3.0 volts, the thing wouldn't program at the start of the day. It just said·chip connection failed. I needed to bump the SX48 to·5.0 volts before it'd accept any programming. Now, after that initial bump, it will program again at 3.0 volts.
Has anyone else here done any amount of programming/debugging of these IC's at 3.0 Volts?
Tnx
-Dan
P.S. Rant: The data sheet says these chips will work at 3.3, 3.0 volts, and Parallax even sold the SX-Key Ring for a while (a low voltage SX-Key adaptor), but I've never been able to get these things to be stable at anything less than 4.5 volts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Can't seem to get my SX48 to debug at 3.0 volts. SXKey is at 5 volts. The thing programs (incorreclty???), but won't run or debug at 3.0 volts.
If bump the chip to 5 volts, it program, it·debugs, and runs as normal.
At 3.0 volts, the SX-Key software won't allow me to reset the device. Can't even tell if the chip is working. The SX-Key just starts up clocking the chip, without·giving me the·option·choosing·walk, run etc. ·It just starts "Running",·and all of the buttons are greyed out.
See attached image. Can't·run the other·hardware at 5 volts, Will burn up·IC's.
Also, note of interest, with the key at 5.0 volts and the Chip at 3.0 volts, the thing wouldn't program at the start of the day. It just said·chip connection failed. I needed to bump the SX48 to·5.0 volts before it'd accept any programming. Now, after that initial bump, it will program again at 3.0 volts.
Has anyone else here done any amount of programming/debugging of these IC's at 3.0 Volts?
Tnx
-Dan
P.S. Rant: The data sheet says these chips will work at 3.3, 3.0 volts, and Parallax even sold the SX-Key Ring for a while (a low voltage SX-Key adaptor), but I've never been able to get these things to be stable at anything less than 4.5 volts.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Comments
I'm programming and debugging SX48s all day long at levels down just below 3 volts with no problems.
I'm also using 4MHz internal RC, and 50 MHz resonators at 3 volts. All OK, so its hard to understand what your problem might be.
I'm sure you are aware that you can't debug with a resonator or crystal plugged in right ??
Cheers,
Peter (pjv)
http://forums.parallax.com/showthread.php?p=644066
Hope this helps,
Dan (yes, another Dan with the SAME problem...hehe)
"Officially", the SX-Key is specified for supply voltages of 5V only. Due to some component tolerances, it may work on lower voltages, if you are lucky. Parallax sold the SX-Ring which allows you to feed the SX-Key from an external 5V supply but I'm not sure if this part is still available.
You can build your own adapter on a little proto board with a four-pin header, a four-pin socket, and a barrel-type DC jack. Connect the OSC1, OSC2, and Vss pins straight through from the header to the socket but leave the Vdd pins open. On the header that goes into the SX-Key socket, connect the Vdd pin with center pin on the DC jack, and the outer ring of the DC jack with the Vss pin, and you are ready to go.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I've just built an SX48 module that is setup for 3.3v and will try programming it at 3.3v and see how it works. I had planned on using the SX-Key Ring so I do expect that it will work.
I thought that I read that the new USB SX-Key may work just fine at 3.3v or 5v. Does anyone have the new one and if so how does it work?
Robert
Thanks for the reply. I read through the thread, and I don't think it's a capacitance issue, but I will do some testing tonight.·I have a multi layer board, with no resonator or feedback resistor installed.·The board has very·short traces. On board, there is a·3.0Volt regulator, and that is supplied·with an external regulated 5.0Volt supply. (Very stiff, good bypassing, no noise...· ...I checked it with an O-scope)
Although,·I did start thinking·last night that the·oscillator settings could be interfearing with the debubbing. I'm starting to think this because the chip progammed the first time without any trouble, after that, if I·remove power I need to bump it with 5 volts before it will program again. Also, if I remove power, and reattach it, the current draw is up a bit. Almost like the oscillator is 'stuck' or something. (Just a guess).
Guenther,
Yes, I know that the Key needs 5 volts. I have a custom board with the SX on it. It has a pin header for the Key with 5 volt supply, and 3.0 volt regulator for the SX chip.·This will normally be a battery powered device, with DC-DC regulator supplying 3.0Volts to the SX and other chips.·For testing/programming and docking it is powered with a 5 volt supply that has a linear 3.0 volt regulator·and ORing circuit·supplying the 3.0 volt rail.·I checked everything with a scope, and I'm pretty·it isn't a power issue...
What would really help, is if I knew what to look for on the osc pins. What are the expected voltage levels/thresholds? What's normal for debugging?· Could the oscillator settings be involved here, maybe the drive levels are forcing the voltages on the osc pins, and tricking the debugger into thinking·the chip has a resonator installed?
I'm sort of·grasping at straws here...
Peter,
Yeah, no resonator/feedback/parallel capacitors installed here.·This is the first 3.0Volt device (1/2 dozen 3.3 volt devices...). I've never seen this·before·now, so this·problem new to me.
Thanks!
Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Post Edited (dkemppai) : 1/23/2008 3:12:09 PM GMT
The components on the new SX-Key USB are always powered from the USB port, i.e. with 5 Volts, so the supply voltage of the target system does not matter. Actually, the Vdd pin on the SX-Key USB is not connected to keep the SX-Key and the target device's supplies separated.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
More info. Today my first error is "VPP Generation failed" (At·5 volts or 3 volts) So, I·just checked OSC1 and OSC2 to ground.
OSC2 measures 4Meg, and OSC1 measures 1K.
I lifted the OSC1·pin of the chip off the board, and my board to ground is open (according to·my fluke 189)
I measured to the actual pin on the chip to ground (It's suspended in the air). It still measures 1K (Both polarities).
I checked a few Parallax proto boards, and they check·~5Meg to ground (Same polarity as I used on the other board).
So, am I up against a·bad chip???· (I'm working on a·good static mats, and have a well grounded soldering station...)
More to come...
Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Well, how do you like this one for coincidences...... Yesterday I posted that I never had a problem programming or debugging SX48s at 3 volts. Today the story has changed, and while I can program them fine, I had some strange results in debugging as well as running programs. But not consistently.
So I was able to track my problem down.... a very subtle situation, and Dan your problem may be the same although it had nothing to do with 3 volts or 5 volts. And I think this issue holds for SX48/52 only, I do not believe the SX28 family suffers the same way from these symptoms.
A couple of interactive things are afoot here. So it turns out that the current documentation, Rev 1.5 datasheet of the SX48BD has (at least) one error in it. It states (page 41) what the register states are after various reset scenarios, and in particular we are interested in the FSR register (the only one I have messed with), and it is incorrect ..... my findings are that with EXTERNAL reset, that is grounding the MCLR pin, the FSR always returns to 00 and not to 8X as stated. The implication being that RAM bank0 is selected (not visible in the IDE), and writing to memory locations in this bank can be problematic as they are not conveniently accessible. So while you think your progam is doing the right thing, it's messing with a piece of invisible memory.
Now the second part. Note that on that descriptive page 41, at the bottom Note 3 indicates uncertain and inconsistent behaviour by the debugger as to the state it is leaving some registers in. I believe that it should be expanded to cover the FSR as well, and perhaps other registers I have not delved yet into, or other reset sources The debugger leaves the FSR seemingly willy-nilly, in all manner of banks; even on reset. Please note that pressing the RESET button on the IDE's debugger control panel yields very different results from a physical 'hard reset' on the chip's MCLR pin.
So what all this means -at least in my case- is that uncertain starting conditions of the FSR can cause initial programming statements (typically configuration stuff) to end up in an unexpected area of memory, and the debugger is the instrument that leaves it in that inconsistent and unknown state.
So my solution now is to have the very first instuction after the reset jump from $FFF be a bank$10 statement to initialize the FSR properly. And why I had not knowingly run accross this situation before, is that I almost always start my programs with a standard template, and that happens to have the requisite bank instruction early enough to point at the desired memory and yield proper results.
Experiment with this and try it Dan, it might be the answer for you, and please do·let us know how you make out!
Cheers,
Peter (pjv)
Post Edited (pjv) : 1/24/2008 12:58:21 AM GMT
I tried to reduce capacitance by using point to point wiring. No luck, still won't work at three volts.·See attached images.
I didn't bother trying to calculate the capacitance, but I'm guessing it's pretty small.
A pair of #40 wires about .5 inches long each·at an average distance of about 1/16th of an inch...·· ...the C·should be small enough·[noparse]:)[/noparse]
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Anyway, I tried your suggestion, and it didn't fix my issue. I still can't debug at, or even RUN at 3.3 volts. I tried lowering the system voltage once the chip was up and running, and the debugger just stopps at 4.09 volts. Below that, nothing. Above that, everything works as expected. I was watching the OSC2 pin with a scope, and it appears that line never gets to a high enough voltage level to let the debugger know that it's ready to run.
The only thing I have tied to the SX on this board is the SX Key, a 10K MCLR pullup resistor, and 4 SMD 0603 bypass capacitors and one SPI DAC. I've built FPGA boards (150Mhz), Optical communications circuits, Pic boards, SMD RF transmitters, high precision analog circuits, and hardwired logic, and I've never ever had as much trouble with anything as this stupid little chip. I'm going to very serously start looking at some of the other MCU's out there. This thing is just to difficult to get to run at 3.3 volts or under.·Unfortunatley for this project, I'm married to this chip.
-Dan
P.S. As for the 1K Ohm to ground, I replaced the chip, and that fixed the "VPP Generation failed" error. But, I'm still having problems getting this chip to do anything below 5 volts. So, at least 1 bad SX out of the box.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
So, go figure ! If you could send me a complete, or alternately a minimally populated board, you know, one with enough components to demonstrate the problem, but not enough to give any secrets away, I'd be happy to have a go at checking it out for you.
Otherwise please PM me your code, and I'd have a go at that. I'm sure this can be solved. We would not want an unhappy SX user out there...... these chips are the greatest!
Cheers,
Peter (pjv)
PS Is there any way you can publicize the other (register) errors in the documentation??
Last night, I was thinking about other things that I could be doing in code that could be problematic. I was wondering, can you post some of your initalization·code·(Just the directive/startup stuff?).·Basically I'd like to start with·the directives you're using, since they seem to be working for you. It would give me a starting point, to add a few lines to try debugging with.
At least, With the·Point to Point wires in the air, I'm comfortable it's not a capacitance issue, which is·one possibility eliminated.
The good news on this project is that my customer is on a long term contract. There is a lot of time to debug things...···
Thanks for your help.
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
I'll try to do that later today...... tough schedule on a project.
Regarding capacitance, that is a red herring. Albeit, the OSC pins can not tolerate much loading, but unless one has a really crappy layout with osc lines many inches long it's not the problem.
Cheers,
Peter (pjv)
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Well, this was troubling me enough this morning (could not program the SX48 worth a hoot) that I decided to dig a little deeper. After a number of hours, I'm a bit smarter, but not a whole bunch.
I've come to the conclusion that it really has very little to do with 3 or 5 volts (although that changes the oscillator characterization some), but far more with the oscillator frequency.
The only reliable way I was able to get my unit to reset, was to use an external hard reset button (debounced) into the chip's RESET line. That brought it back to earth every time. So I went on the hunt for the issues of programming the chip, and then seeing the greyed-out control buttons in the IDE control panel. I remember now that years ago I noticed that if one programmed a chip (SX28 as well as SX48 as far as I recall), and then changing the oscillator frequency in the source code, and then re-entering debug WITHOUT reprogramming the chip, that then the IDE was inoperable, and the buttons would be greyed-out. When one brought the source code frequency back close to the frequency, say within 5% of what it was programmed to in the initial debug session, (not the re-entered one) that then things would work again. I think our troubles are either related to this issue, or this issue is a manifestation of whaterver causes this behaviour.
So I did a bunch more things. When a debug session is programmed, the IDE and SXKey burn your source code as well as the debug code into the chip. And because the IDE is aware that you will not be running the chip's oscillator, but the Key's synthesized oscillator instead, the IDE selects an oscillator setting of OSCHS1 regardless of what you put in your source code. This can be proven by burning some code in debug mode, and then entering the DEVICE window under the RUN tab, and pressing the READ button. It will read back the actual contents of the chip, including your compiled code as well as the debugger code and chip settings- provided that is you had not programmed it with the security scrambler enabled.
So now in reading the chip, the debugger is confirmed in the IDE's memory. Then if you click one of the other OSC setting buttons in the DEVICE window, say OSCHS3 and then press the PROGRAM button while still in the DEVICE window, the Key will now happily re-program the chip, but with the changed OSC setting. Again confirm this by READing it back after the programming is done.
My experimenting indicated that depending on the frequency setting choice in my source code, using oscillator amplifier settings different from the debuggers default OSCHS1, I could now get the IDE debugger to work totally reliably, and at either 5 or 3 volts. Perhaps there is some amplifier sensitivity or gain change with different voltages.
I also did a mess of looking at the data interchange between the SXKey and the chip while pressing buttons on the debugger. Principally, the Key oscillator runs at whatever frequency specified in your source code at the time the debugger is programmed in, OR RE-ENTERED. So the oscillator in the key can be altered by re-entering the debugger without reburning the chip. Then, when a data interchange is required between the Key and the chip, say due to pushing a dubugger RUN, STOP, or RESET button etc, then the Key's oscillator switches to 20Mhz for abou 40 uSec while the OSC2 pin sends commands via level shifting. I imagine this is to get the chip to dump it's memory and status contents most quickly to the Key for passing on to the IDE. Afterall, the IDE's response time to data dumps seem to be consistent regardless of the operating frequency of my program.
There appear to be about (varies) 28 data packets exchanged, not sure of the number of bits in each packet.... probably 8. Then, the thing goes through more gyrations, as well as the 12 volt 'attention'/programming pulse, and then a bunch more data exchange. Probably the first one was IDE/Key to the SX, and the second the response of the SX to the Key.
Anyhow, a bunch more time needs to be spent on this to more fully characterize the operation, and time is too precious just now. But I thought I would share what I found so far, and I'm pretty sure that messing with the oscillator amplifier settings in the DEVICE window will yield you some positive results... it has for me, but I can't yet fully explain it.
In the meantime, I've now got to get back to furthering my project..... more (much) later, unless I hit another brick wall like this morning.
Cheers,
Peter (pjv)
Post Script:· Oops, I almost forgot; yesterday I said that adding a bank$10 as the first statement solved my problem. It did, but not permanently, and my problem re-appeared albeit very infrequently. Then I remembered the in the SX48 (not SX28 series)·one must deal with bit 7 of the bank seperately, and hence one cannot achieve the desired results with a simple bank statement; one must use "mov fsr,#bankno". That sets fsr up properly.
Post Edited (pjv) : 1/24/2008 8:27:10 PM GMT
Just for grins, what is the date code on the SX48's you are having trouble with?
FYI, I noted that the level shift voltages never reached the same thresholds from OSC2 at 3.0 volts as they did at 5.0 volts. I tried a few pullup/pulldown resistors, and there seems to be a pretty stiff relationship (diode???)·to·voltage·SX48 +supply lead.
I'll try some different·oscillator settings·(as you mentioned)·when I get back to my bench tonight, and let you know what I find. I wish I had more time right now, but until the weekend I'm stuck at my day job for most of the working hours of the week...
Thanks!
Dan
P.S. I'm not pleased to see you having the same trouble, however the·company is welcome in this boat!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
I read your earlier posts and maybe I misunderstood, but it seemed that you were trying to program the chip with less than 5V. It's my understanding that it won't work at all like that. It has to be programmed using 5V or it pretty much will be intermitent at best. However, once programmed, it will run at less than 5V. The only way I have reliably debugged at less than 5V is with the KeyRing. You can build one, as was suggested earlier, since it is no longer sold.
I know your board has already been designed, but if you need to redo it, there are ways to run the chip at 5V and the rest of the board at 3V and wire the inputs to accept the signals with the different voltages. Of course, it would be great if you didn't need to do this, but....
Obviously you have alot of experience designing circuits, so I hope my suggestions don't sound rediculous. I just wish I had the magic answer for you.
Dan
·
Had another SX blow last night. The "VPP Generation" Error popped up again. Checked OSC1 to ground, and it was 183 Ohms! So, I'm thinking WTF!· I replaced that SX, and·ALL of my·the problems went away. I could program and debug at 5 volts, and 3.0 volts...
·
Then I started checking a few things. I threw the fluke between my scope ground and PC ground. .002 volts max, .001 volts min, so that was acceptable.
·
Then I threw the meter between·my scope ground and my power supply ground. Same story, very low voltage. Then I turned the power supply on. And I got a peak measurement of 31volts, to my scope ground! Now·something to start looking at! So, I throw the scope probe on the supply ground, and I see a 60Hz 76Vp-p signal. Ah-HA! Power supply is now suspect. The ground lead of the supply isn't ground, it's floating!·Apparently it's meant to be a floating supply! Except, that·the thing appears to have capacitive·coupling to the AC Mains (through the transformer, probably?!?). For·grins I measured the·AC current between the grounds, 13uA (very small). So, my·solution was to·tear into the supply, and place a 10uF·100V poly cap·from·the supply ground to earth ground. The measured voltage is now·2mV Peak to peak between the·grounds.·(The capacitor solution will allow me to float the supply if necessary, yet it·swamps the leakage capacitance in the transformer...· ...I may add a bleeder resistor to ground tonight.)· A quick calculation shows that the transformer capacitance is on the order of 270pF...···
·
Anyway, I'm guessing that the high voltage was stressing the chips, and pushing them close to failure and they wouldn't work at 3.0 volts. (Still seems a bit weird, as overvoltage·failures are usually catastrophic). It looks like,·Eventually the chips would fail, then nothing would work...···...Overall, things·seem to be working again...··· ...until the next weird thing...
·
Thanks again·for all who replied, and helped!
·
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Congratulations! Glad to learn that you finally found the reason for your troubles. Noaw, after you have described the reasons, it came back to my mind that I had similar problems with a power supply that caused a lot of trouble with one of my very first SX projects.
Nevertheless, I can only confirm again what Dan (the DosManDan) mentioned: The serial SX-Keys, and all SX-Blitzes are specified for an operating voltage of 5V. When you can successfully operate them at lower supply rates, you are lucky, and have one, where all component tolerances "add to the right direction" -[noparse]:)[/noparse] . To my experience, the SX devices can wery well be programmed when powered at lower voltages, as long as the Key/Blitz are "fed" with 5 V.
Good luck, and don't send more SXes into "semiconductor's heaven".
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Interesting..... my situation of not being able to debug (programming at 3 volts had always been fine) did not stem from any power supply issues. Infact my setup has been identical for weeks.... same everything; an SX48 on a 40pin carrier DIP plugged into my PDB. Perhaps some minor temperature changes in the building....
Dan, eventhough your problems appear to be solved, I strongly reccommend you mess with the clock frequency and amplifier settings while in the debug mode and observe the strange goings-on.
Cheers,
Peter (pjv)
I did play around a little, and found that changing the oscillator settings·didn't affect much on my board. I will continue to play round with them as this project progresses.
As an FYI, I did notice that·changing the brownout setting·to the 4 volt setting on the device·screen caused the SX to act eerily similar to my·debugging problem.·[noparse]:)[/noparse]· ·So, I DO KNOW·there is at least one directive that will break the 3.3 volt debugging.· It's one that I'll have to keep in mind if I run into this type of issue again!
Anyway, keep me posted on your troubles.·If there's anything I can do to help you out, let me know!
Thanks!
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
during a debugging session, the OSCx setting does not make any difference, as the device under test is always externally clocked from the SX-Key through the OSC1 pin with the internal clock oscillator turned off, as the OSC2 pin is required for the communication between the SX-Key and the SX under test.
When running stand-alone, it might be necessary to increase the internal oscillator driver gain by selecting a higher OSXxxx setting at lower supply voltages, but this also depends on the resonator/xtal type you are using. You also should consider selecting a higher gain in case the running system might be exposed to lower environmental temperatures.
Sorry, I forgot to mention the brownout setting before, because I thought this was obvious. No matter if you are debugging or run the chip stand-alone - you must always set the brownout level to a value lower than the supply voltage, or turn it completely off.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
-Dan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Recap.·Part of the thread were SX Chips were burning up, on powerup.
Took a while, but finally got to the bottom of this. Project is since done, and I though it would be a good idead to share with everyone the actual problem.
It turns out, that at at random and not very often, when the SX Key looses power, it generates a VPP transient. In certian instances this transient can latch up the osc pins of the target device. If the cicuit is repowerd just after this happens and a programming cycle is started, the latched up SX target or SX-Key can be destroyed by the SX-Key VPP generation. This seems to be more of a problem when the device being programed is at less than the VCC supply of the SX-Key.
This should only be a problem with the Serial key. The issue has been addressed on the USB key.
Anyway, bottom line, here when using a serial key to work on target devices under 5.0 volts, UNPLUG they Key before you power down the VCC supply. Plug it in after the VCC supply is stable. Probably not a bad idea even for 5.0V system voltages...
-Dan
Peter, I was not nuts! It took blowing up half a dozen target devices, and 8 SX-Keys to find this issue...
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
"A saint-like quantity of patience is a help, if this is unavailable, a salty vocabulary works nearly as well." - A. S. Weaver
Post Edited (dkemppai) : 9/27/2008 2:58:38 AM GMT