PIC24EP512GU810 problem

[championx]

Hi! I'm developing a board that has a PIC 24EP512GU810, and I'm testing the third version of the board... the previous versions works fine, but this one i can't make it run... the weird thing is that when i put the oscilloscope probe on the OSC pins i get for a short time a correct sinusoidal wave and then it goes to ground... i see this repeatedly... all the time...

I assume that the board starts for a few milliseconds and then it resets... i have checked all the traces, components and voltage levels and are ok... exactly the same as the previous versions...

Is there something that I'm missing? is there something that can cause this behaviour? (osc starts then stops... starts... stop... etc)

thanks

[newguy]

What frequency is the crystal frequency, crystal caps = ?, and if you have a series resistor, what is its value?

Can you change your code to use only the internal oscillator? What happens then? Can you start using the internal oscillator, then perform a clock switchover to the crystal?

Just having a quick look at that processor's errata gives me an ulcer.

[temtronic]

while I don't use that PIC...
1) what is different in the PCB layout or component values ?
2) try basic '1 Hz LED' program
3) read all the errata pages
4) does a PIC from a working PCB fail in the new PCB?

Jay

[Ttelmah]

Is it possible that the new board is using chips from a different batch?.

Do you have the parallel 1MR resistor across the crystal?.

If you look at the data sheet (Figure 9-1 Note2), you will see that this is 'required'. However I've seen batch based variations on this. Some chips will run fine without it, but on others the oscillator will not start, or if it is started by an external kick, it then stops after a while. Exactly fits what you are seeing.

Temtronic's last question, reflects this possibility....

[championx]

Thanks for all your Help, answering your questions:

- It is a different PIC batch.
- The PCB only changes on external connectors and some traces... nothing changes on the VDD, VSS, MCLR, OSC and VDD core pins...
-I tried the 1Meg resistor in parallel and it didn't start the osc.

I will try to use the internal oscillator, do you have a working code configuration for this? It is very confusing how many modes there are.

And last of all... if nothing helps, i will replace a working board pic to this new board and check if that's the problem... The thing is that the pic is SMD TQFP100.

thanks!

[jeremiah]

Without seeing your FUSES and startup code, it is hard to say completely, but with PIC24 fuses, you normally need to change:

PR => FRC
or
PR_PLL => FRC_PLL

And set your HS,XT,EC FUSE (whichever you picked) to NOPR

And you would need to change your clock statement to match the internal

something like:
#use delay(clock=XXXXXXX)
or if you use a PLL
#use delay(internal=XXXXXXX,clock=YYYYYY)

Where XXXXXXX is your FRC frequency from the datasheet, and YYYYYY is your frequency after the PLL (if you use the PLL).

Aside from that, I don't know what code you put in for your clock.

[newguy]

http://www.ccsinfo.com/forum/viewtopic.php?t=47757&highlight=crystal+switchover

Look at the last post. This is for a dsPIC33-series processor but the procedure for yours will be similar.

[jeremiah]

As a note on that post, there are a lot of things you should consider:
1. You have both FRC and PR_PLL selected. These are conflicting fuses. I think the PR_PLL overrides FRC because of the order.

2. The second #use delay() statement is a "precompiler" directive and does not belong inside of functions. It does not generate run time code at that location by putting it there. It should be right below the #fuses.

3. There is a setup_oscillator() method that exists for what your setup_pll does. I actually just got through showing this to a coworker who did the same as you did for his dsPIC.

4. Your first #use delay() indicates an internal oscillator.

Not to say what you have doesn't end up working, but that the journey you had to get there can be problematic and create really nasty bugs later.

If your intent was to start with the FRC and switch to the high speed crystal later, I would have done the following:

[newguy]

Your method was tried but didn't work with that chip and v4.141. Because of a crystal issue, found when I bought the CCS DSP Analog development kit, the kit just wouldn't reliably run at all. Buried in the processor's datasheet was a note that the oscillator wouldn't always start if using an external crystal with PLL if the crystal's value was above some threshold. The 12MHz crystal on the development kit was above that threshold. The method in the post was and is the only way to get that processor running with a 12MHz crystal and PLL 100% reliably with v4.141 of the compiler. ...The only that I've found, anyway.

[jeremiah]

[championx]

Hi, im trying to use the internal oscilator, but I dont know if this config its ok:

[Ttelmah]

I think you will find the internal is fixed at 7.37MHz (it is on most PIC's in this family).

[jeremiah]

I'd have to go back and look, but I would think the SOSC fuse is a competitor to the FRC_PLL one (it tells the main clock to run off of SOSC), not a separate fuse. There is a fuse that controls the SOSC, but it is normally named differently.

Still, I think since FRC_PLL is after SOSC, it will overwrite it, so you should still be ok if so.

I would write a small empty test code, then look at the LST file to see what the actual fuses are (they can be different than what you put in the top of your code). Then you can compare them to what you specified.

[championx]

well... damn... it works with this fuses:

[temtronic]

hmm..
same batch of xtals ?

maybe test xtal/caps on a breadboard and a simpler PIC ??

possible solder bridge/ flux not gone problem ?

I don't use SMT PICs, too dang small for my old eyes !

Jay