dsPIC30F3014 using PLL

[temtronic]

You should post your complete program,so we can see it, and others can cut/paste/compile/test on their bench.

You need to be real careful about 'FUSES', do NOT assume if you don't edit them, that they WILL work for you ! Some 'default' option may not be what you want.
When I started using the PIC18F46K22, I created a '46k22fuses.h' file that has every fuse listed, one per line, with comment at the end. If a project needs a configuration other than the basic 'working' version, I copy the original, make changes, and save with a filename that has the project embedded in it.

This does 2 things for me.
1) the fuses file has EVERY fuse in it,so I can see what they are...
2) since the fuse file is now a #include, it makes 'main()' easier to read.

[Ttelmah]

On your pin not toggling at higher speed, it depends totally on what is
attached. Using 'output_toggle' has the problem that this works by
reading the pin level, inverting this, and writing this back to the pin.
Now if the pin is attached to something capacitive, it may well not
change to the level specified in 2uSec. Result the toggle stops working.

Having brownout enabled, should make the chip physically reset for 90%
of supply droop problems. However won't affect things like noise spike
problems. Realistically, you are going to have to debug what part of the
code actually hangs. Could be something waiting for an external event, or
a supply spike, etc. etc..

[MCUprogrammer]

Most of the problems have been fixed in the dsPIC30F3014.
#use delay(clock=100MHz,crystal=25MHz)
Now there is another problem. I increased it to 100mhz with 25MHZ crystal in the attached program. I'm toggle with PIN_C13. Output is always at 0, no pulse.
#use delay(internal=120MHz)
When I write the code above, the same problem still persists.
When I just connect a 25MHZ crystal and create a 1ms interrupt, there is a nice pulse. Could the problem be with the compiler?
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[newguy]

I don't have time to download this particular PIC's data sheet, but one thing that has bitten me in the past is slew rate control, which by default is usually on. That is enough to completely suppress any high speed things you want to do, like toggling a PIN every few us.

[MCUprogrammer]

@Ttelmah the code below didn't work.
#use delay(clock=100MHz,crystal=25MHz)
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[MCUprogrammer]

@temtronic can you share this 46k22fuses document
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[Ttelmah]

[Ttelmah]

[MCUprogrammer]

I tried but it didn't work. But the code below worked.
#use delay(clock=66.67MHz,crystal=25MHz) this works.
Also, typing #use delay(internal=120MHz) doesn't work.

I'm doing #fuses NOMCLR of the dsPIC33EV256GM104 processor, it doesn't work. What will I do for this?
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[temtronic]

hmm, since it works at 66MHZ and not faster, it sounds like you have the 80MHz version.

this would be called 'overclocking' in the PC world.

[Ttelmah]

The 33EV, has the 'proper' programmable PLL that most of the PIC24's,
and PIC33's have. The 3014 does not have this. It allows you to have
pretty much any clock.
The setting for this is just done by the clock statement. It is not does as
a fuse on this chip. The oscillator is programmed _after_ the chip starts.
Big difference here though is that unlike the 3014, the clock only runs
at 2*Fcy, rather than the 4*Fcy of the 3014. So (for example), with
a 24Mhz crystal:

#use delay(crystal=24MHz, clock=140MHz)

gives you 70MIPS operation (actually gives fosc/3 to PLL - *35 to
give 280MHz, then /2 to give 140MHz).

Any fuses you need, will depend on what you actually want to do. So
for example if using the I2C, you may need the ALTI2C fuse etc..

I'm still worried that his original problem may be decoupling. On the
3014, you need four decoupling capacitors, and all four PSU connections
made. My board had decoupling just a few mm from each pair of
supply pins, and these are fed from power planes inside the board. These
chips are 100* more fussy than smaller PIC's on their supply and
decoupling.

On the 104, you have three sets of supply pins, and the Vcap connection.
The capacitor on this needs to be a low ESR type. I use 10uF ceramic
capacitors for the Vcap. These should be connected with quite thick traces
and only a few mm from the leg.

[MCUprogrammer]

Erratas for devices, I went to the device's web page and looked. here is the link for the one for the PIC30F3014:

https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/Errata/80455D.pdf

Item number 22 in the errata was the one I was looking at.
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[Ttelmah]

The fix for that is to have an INT_OSCFAIL handler, that simply tests
the clock failure status bit (OSCCON:3), and if it is clear return immediately.

It does tell you this in the errata sheet,

[MCUprogrammer]

yes i know. I installed the #INT_OSCFAIL interuppt accordingly. This solves the problem. but there is one more thing i don't understand.
I pulled up with MCLR 10K. It has a reset button next to it.

When I turn on the processor for the first time, the processor seems to do nothing. Turning it on and off a few times fixes the problem. What should I do for this?
_________________
Best Regards...
MCUprogrammer
_______________________________
Work Hard

[Ttelmah]

That almost certainly implies your power supply does not meet the
specified rise time. This is a common problem with the DsPIC's, where
supplies that worked fine for the PIC16/18's, won't reliably start these
more powerful chips. If you check the data sheet, I think it requires a
rise time to 5v that is less than 0.1sec. If you go over this the internal
reset circuit won't work properly.
Two solutions:
1) improve the rise time of the supply.
2) add an external reset circuit to operate MCLR.