CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

A little advice on what not to do with internal oscillator

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
mcr1981



Joined: 27 Oct 2010
Posts: 28

View user's profile Send private message

A little advice on what not to do with internal oscillator
PostPosted: Thu Apr 24, 2014 6:39 pm     Reply with quote

Hello.

Just telling you a little advice on what not to do with the internal oscillator of a PIC24FV32KA302:

do not use the preprocesor #use delay(internal = 31250), it will brick your micro.


At least it's what I think happen to three of my micros. Could program them with 32MHz internal and all the way down to 1MHz, but when I tried to use 31250, they are not recognized by the PICKIT3.

That's so strange since I can't even erase them. I've been looking around the microchip forum and the web for a possible solution and apparently when you use the Internal Oscillator with a frequency not known to the microcontroller and don't use the MCLR pin as a MCLR (normal digital instead) you get yourself a nice little brick.


Here's the sample code I use:


Code:


#include    <24FV32KA302.h>

#DEVICE ADC = 12
#FUSES ICSP1
#FUSES NOWRTB
#FUSES NOBSS
#FUSES NOWRT
#FUSES NOPROTECT
#FUSES NOWDT
#FUSES NODSBOR
#FUSES NOLVR
#FUSES NODEBUG
#FUSES NOBROWNOUT
#FUSES NOIESO
#FUSES SOSC_DIGITAL
#FUSES NOOSCIO
#FUSES NOMCLR
#use delay(internal=31250)



Code:

void main(void)
{
    while(1)
    {
        output_low(PIN_B5);
        delay_ms(1000);
        output_high(PIN_B5);
        delay_ms(1000);
    }
   
}



I use PCD 5.023 and MPLAB X 2.05


Actually, PICKIT3 can read the device (although it tells me it does not recognize it) and the configuration bits are as follows:
Code:


// PIC24FV32KA302 Configuration Bit Settings

// 'C' source line config statements

#include <htc.h>

__CONFIG(BWRP_ON & BSS_HI5K);
__CONFIG(GWRP_ON & GSS0_ON);
__CONFIG(FNOSC_FRC & SOSCSRC_DIG & LPRCSEL_LP & IESO_OFF);
__CONFIG(POSCMOD_EC & OSCIOFNC_OFF & // POSCFREQ = No Setting
 & SOSCSEL_SOSCLP & FCKSM_CSECME);
__CONFIG(WDTPS_PS1 & FWPSA_PR32 & FWDTEN_OFF & WINDIS_ON);
__CONFIG(BOREN_BOR0 & LVRCFG_ON & PWRTEN_OFF & I2C1SEL_SEC & BORV_LPBOR & MCLRE_OFF);
__CONFIG(// ICS = No Setting
);
__CONFIG(DSWDTPS_DSWDTPS0 & DSWDTOSC_SOSC & DSBOREN_OFF & DSWDTEN_OFF);



One can import the configuration bits from MPLAB X.

That's very strange since all the PIC is protected.

The only thing I did was to change the #use delay(internal=32MHz) to #use delay(internal=31250).

Hope this is useful for someone, don't fiddle with the wrong Oscillator Frequency and the MCLR configuration bit.


Will still try to program those micros, but don't know if I'll succeed. Will tell you if I can.
asmboy



Joined: 20 Nov 2007
Posts: 2128
Location: albany ny

View user's profile Send private message AIM Address

PostPosted: Thu Apr 24, 2014 7:23 pm     Reply with quote

bad fuse being written?

what does the end of the offending .LST file show ??

tried a readback of PIC program and fuses area ??
i've done that with PICs,
using the Micro engineering labs USB pic programmers
when situations like this arise, comparing fuses as written
vs what i wanted . Very Happy
jeremiah



Joined: 20 Jul 2010
Posts: 1353

View user's profile Send private message

PostPosted: Thu Apr 24, 2014 9:18 pm     Reply with quote

Your fuses would default to the FRC, which is much higher frequency than the LPRC. You should really set your fuses to reflect your LPRC. There are two to set:

#fuses NOPR //tells the pic to not use an external clock circuit
#fuses LPRC //tells the pic that the clock select mux should select the LPRC

EDIT: also note, these chips (both the 304 and the 302) sometimes have trouble running at frequencies near or above 25MHz. The datasheet says they can go up to 25MHz, but I have had trouble in the past with gliching at those speeds. Simple hello world programs would fail sometimes until I dropped the speed down.

I've never tried using the LPRC as the system clock (I use it for timer1 wakeup from sleep a lot of times) nor do I have a picket3 to test with. I typically go with the FRC or a 3-11Mhz external crystal. Even with those, the PIC24F32KA30x will drop to nano amps in regular sleep, so I haven't needed to run off the LPRC. Also note that the LPRC has a 15% tolerance, so you have to be careful what you run on your PIC.
mcr1981



Joined: 27 Oct 2010
Posts: 28

View user's profile Send private message

Thanks for the replies but....
PostPosted: Fri Apr 25, 2014 1:27 am     Reply with quote

Thanks for the replies.....but:

I tried reading the PIC and it returns just NOP in every line (in HEX they are all 0x00).

When I read the configuration bits it always returns code protection to the max (can't read or write).


Can't erase them. Not even with a Xeltek SUPERPRO 5000E (same error, can't read the device).


Even tried with MPLAB 8.92 (trusty MPLAB). I remember several times I just went into the configuration bits area and forced MPLAB to program new configuration words.



To Jeremiah:
That's odd, the high frequency issue. I've been using these micros with some PWM, RS232, LCD and other stuff at 32MHz (8M FRC+PLL) and haven't had any problems.... well, having problems now at low frequencies.


Will order new PICs and see what happens. Will not give up on those three little bricks that I now possess. Crying or Very sad

12:26 AM now.... need to sleep.
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Fri Apr 25, 2014 9:00 am     Reply with quote

sounds like you should contact Microchip and ask for help...at least they should replace the 'bricks' for free....

jay
mcr1981



Joined: 27 Oct 2010
Posts: 28

View user's profile Send private message

Contacted Microchip now.
PostPosted: Fri Apr 25, 2014 12:26 pm     Reply with quote

temtronic wrote:
sounds like you should contact Microchip and ask for help...at least they should replace the 'bricks' for free....

jay



That's news to me. Hopefully they will resolve this issue.

Will contact them and wait for a solution.


It's interesting that the Low Power RC configuration bits don't change. Looks like it's always working with the nominal internal frequency (8MHz).



EDIT:
Ticket has been created, now to wait.
270265 04/25/2014 05:33 PM
Ttelmah



Joined: 11 Mar 2010
Posts: 19535

View user's profile Send private message

PostPosted: Sat Apr 26, 2014 1:18 am     Reply with quote

I remember before, finding on these chips that the 'internal=' usage, does not switch to the LP oscillator. You have to explicitly select this in the fuses. So LPRC.

Just compiled with this selected, and imported to MPLAB, and the FNOSC fuses then change from the 8MHz with postscaler, to the LPRC oscillator.

On your ability to read the fuses, this sounds suspiciously like the old MPLAB switching to DEBUG mode problem. So several of the actual fuses are being overridden, including the ones that prevent the fuses from being read.
mcr1981



Joined: 27 Oct 2010
Posts: 28

View user's profile Send private message

Update....
PostPosted: Sun Dec 28, 2014 5:28 pm     Reply with quote

I have not tried this code with the faulty oscillator since the last time.

I'm surprised to see that the new version (5.035) does provide an error if one tries to assign an invalid internal oscillator with MPLAB X 2.26

CCS with the help of the ICD-U64 and tech support helped me a lot too.

Microchip reproduced my setup and they too bricked their chips.
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Dec 29, 2014 2:24 pm     Reply with quote

hmm.. the fact that uC bricked their own devices says to me, they should send you new ones !!

It should NOT be possible to do. There should always be a way to 'reset' the PIC to a 'factory configuration'.

jay
mcr1981



Joined: 27 Oct 2010
Posts: 28

View user's profile Send private message

I hear you...
PostPosted: Mon Dec 29, 2014 2:47 pm     Reply with quote

Already told them that back in April 2014. Well, not that exactly like that.

Those chips were revision 4. Got new ones and now they are revision 6.

I'm just happy it works now and the CCS guys now have implemented that feature for the internal oscillator calculation.

If there's a way to destroy something, someone will find it..... I always say that, now I'm part of my own statistics Laughing



EDIT:
was not April 2013, it's 2014.


Last edited by mcr1981 on Tue Dec 30, 2014 12:45 am; edited 2 times in total
temtronic



Joined: 01 Jul 2010
Posts: 9241
Location: Greensville,Ontario

View user's profile Send private message

PostPosted: Mon Dec 29, 2014 5:07 pm     Reply with quote

hmm.. when I told them 'something' was wrong with my PicstartPlus (failed to update the new PIC internals), they sent me a new one, next day from Toronto, kinda supriseed they didn't send you a 'tube' full of new PICs. Glad to hear you're 'up and running' though !!

jay
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Mon Dec 29, 2014 5:13 pm     Reply with quote

It's possible you could get a limited number of replacements as samples.
http://www.microchip.com/samples/Default.aspx?DeviceFamily=PIC24F32KA302
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group