Post by thread:Re[2]: Oscillator problem on 12C50X series, OTP &

Kalle, Yes, Todd called me directly and we finally determined that his problem was with the PICSTART programmer. There is a bug in the PICSTART programmer that when you are in simulator mode, it will let you change the calibration constant, program a part and tell you that it did it when it really didn't! To see this, switch to editor only mode in MPLAB and read the part, the calibration value will be read correctly. This problem will be fixed in the next version of the PICSTART software due out quite soon. There are no errata on the 12C50X parts at this time, and there are no anomalies that we are aware of at this time that we are checking out. The internal oscillator works correctly, including the OSCCAL register. Best Regards, Scott Fink Microchip Technology ______________________________ Reply Separator _________________________________ Subject: Re: Oscillator problem on 12C50X series, OTP & JW Author: Kalle Pihlajasaari <spam_OUTkalleTakeThisOuTDEVICE.DATA.CO.ZA> at Internet_Exchange Date: 2/11/97 8:32 AM Hi Todd, {Quote hidden}> I have spoken with Microchip extensively (as well as with several others > experiencing problems) and Mircochip assured me that either (A) I am a > fruitcake, or (B) the ambient room light where I program the JW parts is > what is making the JW's not work and the OTP's work. They suggested the fix > of covering the parts before each program with a sticker and insist that > there is NO 'bug'. Anyone else with experience in this matter? I can make > the OTP's work fine, and can easily set the cal. constant 'on the fly' with > both types; it is just when setting the constant on powerup in the JW's that > causes trouble. > > Anyone with similar experiences please e-mail me privately; I have heard > privately from several of you already. I am trying to gather more data on > the situation. However, the 12C508's are my favorite device yet. Keep up > the good work, MCHIP. And we obviously want 8-pin derivatives with EEPROM, > A/D, and slave I2C. Hardware PWM would be nice too. It's funny how the symptoms can hide so well. I posted a program to test the OSCcal function and have made tests but when I finally got around to tidying up the code and placed the movwf OSCcal instruction to the first instruction, well you guessed it the callibration did not take. This seems so wierd that I almost fell over and I think it is responsible for my earlier suspicion of having used the wrong OSCcal value (I was indeed but only on one JW device) so it looks like some of the JW devices exhibit this cute behaiviour. I have read ALL the PIClist traffic on the C508 (40 messages) and there were no final answers on this issue. I did cover the window to no avail. I considered soldering a metal cover on but thought I would leave that as a last resort. Instead I changed my code. There was a complaint about how to reliably get the OTPs to do their thing and it's was not that hard, I just placed 4 of the movwf OSCcal instructions as the first 4 and it seems to have worked fine. The error I saw was about 18% and this tallied with my '70' cal device at the uncallibrated 'F0' value. I'm uncertain if the register should default to 'F0' or '70' but it seems to get a 'F0' when this symptom occurs. Callibration information available at the folowing URL for those just joining this thread. http://www.ip.co.za/people/kalle/pic/default.htm#caltest There is a short program that can be used to determine a lost JW part callibration value with the aid of a frequency counter (100 kHz). Was there any final resolution or is this madness contagious :-) Cheers -- Kalle Pihlajasaari .....kalleKILLspam@spam@ip.co.za http://www.ip.co.za/ip Interface Products P O Box 15775, DOORNFONTEIN, 2028, South Africa + 27 (11) 402-7750 Fax: 402-7751 http://www.ip.co.za/people/kalle DonTronics, Silicon Studio and Wirz Electronics uP Product Dealer

At 09:46 AM 2/11/97 -0700, you wrote: > Kalle, > > Yes, Todd called me directly and we finally determined that his > problem was with the PICSTART programmer. > > There is a bug in the PICSTART programmer that when you are in > simulator mode, it will let you change the calibration constant, > program a part and tell you that it did it when it really didn't! > > To see this, switch to editor only mode in MPLAB and read the part, > the calibration value will be read correctly. > > This problem will be fixed in the next version of the PICSTART > software due out quite soon. List Members, Sorry for the delay in posting the working solution - I have been away and also wanted to verify the solution. It seems this is the problem; to solve it (until MPLAB is fixed), just make sure to switch over to EDITOR ONLY mode when programming, or else the cal. constant won't be written. Doing this solves the problem. -Todd .--------------------------------------------------------------. / .-. E-Lab Digital Engineering, Inc. .-. \ | / \ Embedded Control & Integrated Circuit Solutions / \ | | \_. | | / | |\ | /| http://www.netins.net/showcase/elab |\ | /| | `---' | | `---' | | | EDE700 Serial LCD Display Driver IC coming soon! | | | |--------------------------------------------------| | \ / \_____/ `---'

> I have read ALL the PIClist traffic on the C508 (40 messages) and there > were no final answers on this issue. I did cover the window to > no avail. I considered soldering a metal cover on but thought I would > leave that as a last resort. Instead I changed my code. > > There was a complaint about how to reliably get the OTPs to do their > thing and it's was not that hard, I just placed 4 of the movwf OSCcal > instructions as the first 4 and it seems to have worked fine. The programmer I've developed for myself will test address $1FF (on a '508) or $3FF (on a '509) before programming. If that address holds a MOVLW in- struction and the user code (.hex file) also holds a MOVLW instruction, the instruction in the .hex file will be ignored. If I ever have a real need (and actually get some window parts!) I may modify the programmer to figure out the calibration value on the window parts; as I've posted here before, I think it should only be necessary to sacrifice eight locations in EEPROM to test and set the proper calibration value.