It feels as though I am blazing new territory. And now that I hear the 18F252's are only available as samples, that sounds about right. Anyway I have made the following observations so far, with the ICD-2. Since it's still not working, I'm not sure if any of this would change once whatever it is, is fixed. If I disconnect the cable from the target, and try to program the target, it programs it anyway. That is, the programming pass is apparently write-only. So, as they say, "no errors are possible". On the verify pass, it says the the target doesn't match the code. That's a little closer, but it still doesn't realize it's talking to "air". Not until it tries to talk to the debug innards does it realize no one's there and time out (but it does that even when hooked up.) I would suspect it of not reading at all except that it will verify a program that's put in without debug enabled. Another odd behavior is with the clock. The '252 gets a 7 MHz clock on OSC1, and I check OSC2 with various oscillator configurations. With HS I see the signal on OSC2 although it's had all the high frequencies removed. With RC, XT, and LP, nothing comes out that pin. I have subsequently discovered more settings for this chip. Of particular interest is "external" (which is actually the obvious choice) with the clock/4 available on OSC2. That doesn't work. I keep hoping to find some detectable signs of life on that thing. Bad chip? Lo and behold we had another board. Same behavior. Bad cable? I tried the one off my ICD-1 and it's the same. Bad ICD-2? Well, I hate to blame it on bad parts but at some point you just have to try. We're getting another ICD-2 next week sometime. I'm still expecting to find some kind of default automatic sleep-on-hardware feature here but theoretically this chip is a spittin' image of the 16F876 that we were using before. Oh, I did wave a dead fish over it. No correlation. Thanks for listening. Barry -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu