• AVR Freaks

AnsweredHot!dsPIC33CK Fcy Frequency

Page: < 1234 > Showing page 2 of 4
Author
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 18:28:07 (permalink)
0
I finally made it back to the office and have an update:
  1. I soldered a set of 0.1uF and 1pF low ESR ceramic caps across each pair of Vss and Vdd pins directly on the breakout board headers.  This is as close to the pins as I can reasonably get.
  2. I ran the system off a linear bench power supply calibrated at exactly 3.3v.
  3. All unused I/O is configured as output and driven low.
  4. I tried both the PICKit3 and ICD3.
  5. I tried all the PLL settings that are valid and create a 100MHz Fcy
  6. I tried a second dsPIC33CK256MP506 obtained from a different source, soldered on a totally different board, with the 0.1uF and 1pF low ESR caps.
  7. I placed a scope probe on a set of power pins to confirm that there is no high frequency noise.
I still cannot get the dsPIC33CK256MP506 to run at all at a 100MHz Fcy.  As soon as it switches the clock from the FRC to the PLL, it causes errors during debugging that force me to reset the programmer and sometimes MPLAB X (v5.05).  If I try to run it without the debugger, it still does not toggle the pins I have configured nor does it output any clock on the configured pins.  If I change the PLL to a 90MHz Fcy, it runs perfectly every single time.
 
If this is some sort of hardware issue on my end, I have never seen an MCU that is so sensitive to the hardware configuration.  I have tested lots of stuff this way over the years and this is the first time I have ever had something not cooperate when there is no errata for the issue I am seeing.
 
EDIT:  I should note that this is a different part than the dsPIC33CK's that other people have had success running at 100MHz
post edited by bhave - 2018/10/03 18:36:51
#21
NorthGuy
Super Member
  • Total Posts : 5493
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: dsPIC33CK Fcy Frequency 2018/10/03 18:32:03 (permalink)
0
jtemples
Strange, Firefox won't display your photo

 
Firefox doesn't like the web server:  "The peer used an unsupported combination of signature and hash algorithm. Error code:  SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM"




Very strange. There's an extension which "negotiates" signature algorithm, and since this is an extension, it doesn't need to be used, so I just ignore it when the client sends the extension. I don't understand the point of this extension at all as the algorithms are already specified when you select your cipher suite. Apparently, Firefox thinks the extension is mandatory:
 
https://bugzilla.mozilla.org/show_bug.cgi?id=1431387
 
No problem, I'll fix this tomorrow.
 
@qhb - Thank you very much for pointing this out.
 
#22
JPortici
Super Member
  • Total Posts : 693
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 00:41:11 (permalink)
0
bhave
EDIT:  I should note that this is a different part than the dsPIC33CK's that other people have had success running at 100MHz



Have you tried contacting microchip support then? You could be onto something..
#23
Howard Long
Super Member
  • Total Posts : 676
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 00:57:38 (permalink)
0
bhave
I ran the system off a linear bench power supply calibrated at exactly 3.3v.

 
Any chance of using an on-board LDO? I don't think it'll make a lot of difference though. Also can you make sure your supply's not current limiting: I've been caught with that one before in similar circumstances.
 
 
If this is some sort of hardware issue on my end, I have never seen an MCU that is so sensitive to the hardware configuration.  I have tested lots of stuff this way over the years and this is the first time I have ever had something not cooperate when there is no errata for the issue I am seeing.

 
Any chance of you attaching a photo of your layout in case we notice anything obvious?
 

EDIT:  I should note that this is a different part than the dsPIC33CK's that other people have had success running at 100MHz



While it's possible, the dies are generally the same, and typically I can reproduce problems with a chip in the same sub family. I'm afraid the only CK I have in stock to try are:
 
dsPIC33CK128MP202
dsPIC33CK128MP508
dsPIC33CK256MP502
dsPIC33CK256MP505
 
I don't think this is the problem, but I'll draw your attention to this in the errata:
 

5. Module: Oscillator
When using the 8 MHz internal FRC Oscillator
with Primary PLL as either a system clock or a
peripheral source, FRCDIVN drives the PLL
instead of the FRC.
This means that the PLL FRC input selection is
subject to the FRCDIV<2:0> bits and could lead
to a condition where the minimum PLL input
requirement of 8 MHz is not maintained.
Work around
Ensure FRCDIV<2:0> bits are maintained as
zero when using FRCPLL as either a system
clock or a peripheral source.

 
#24
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 06:22:57 (permalink)
0
I have my bench supply set up to limit at 1A.  My dsPIC33CK uses 50mA when running at 90MHz.  When I try to run at 100MHz it uses 20mA.  This low current is probably because it appears to hang while waiting for the clock switch to complete.
 
I bumped my bench supply up to 5V and used an MCP1700 LDO with 1uF filtering caps on the input and output.  It did not make any impact.
 
Attached is a picture of my setup.
 
EDIT:  I did see the errata and am clearing FRCDIV before setting up the PLL.  The thing is, I am happy with the performance at 90MHz.  This is a nice update to the dsPIC series.  I am simply bothered that I cannot reach 100MHz.
 
post edited by bhave - 2018/10/04 06:27:51

Attached Image(s)

#25
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 09:54:21 (permalink)
0
Just to debug a littler further, I tried 90MHz and 100MHz Fcy's with 8MHz and 20MHz external crystals.  Once again, it worked perfectly at 90MHz with both crystals and did not work at all at 100MHz.
 
I am going to contact Microchip support and see what they say.
#26
NorthGuy
Super Member
  • Total Posts : 5493
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: dsPIC33CK Fcy Frequency 2018/10/04 10:11:25 (permalink)
0
The specification must have some margin. You should be able to overclock it a bit, say to 120 MHz, without much problems. If it's indeed a silicon problem then you should be able to alleviate it by applying something cold (such as ice pack) to the chip.
 
From what is described here it looks like debugging problem, such as a race condition between debug executive and the debugger. Such things will have an abrupt frequency threshold as you describe. When you tried it without the debugger, you must've made some sort of error - such as programming a debug configuration instead of release, or holding MCLR low. Since you expected it to fail anyway, it's very easy to overlook something simple (for me anyway). Howard could run it at 100 MHz without debugger.
 
#27
JPortici
Super Member
  • Total Posts : 693
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 11:16:44 (permalink)
0
Could you try increasing the frequency in steps?
90,91,92, .. and see precisely when it stops working.
Altough it could indeed be a problem in the debugger because the parts are new..
#28
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 12:57:29 (permalink)
0
I am running using the FRC. 
 
From 90MHz to 95MHz, everything works perfectly and the execution time of some benchmarking code I have running using the DSP built in instructions gradually decreases.
 
The debugger stops working at 96MHz Fcy, but the MCU operates properly when not being debugged.  The benchmarking code execution time slightly decreased from 95MHz:
 
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPRE = 1;
PLLFBDbits.PLLFBDIV = 192;
PLLDIVbits.POST1DIV = 4;
 PLLDIVbits.POST2DIV = 1;

 
The MCU appears to work at 97MHz Fcy without the debugger.  It executes the code, but the execution time of the benchmarking code takes considerably longer than when running at 90MHz Fcy:
 
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPRE = 1;
PLLFBDbits.PLLFBDIV = 194;
PLLDIVbits.POST1DIV = 4;
PLLDIVbits.POST2DIV = 1;

 
At 98MHz the MCU executes without the debugger until it gets to the benchmarking code, then completely stops ... if I remove the benchmarking code, the MCU executes fine:
 
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPRE = 1;
PLLFBDbits.PLLFBDIV = 196;
PLLDIVbits.POST1DIV = 4;
PLLDIVbits.POST2DIV = 1;

 
The MCU functions without the debugger and benchmarking code at 99MHz.  If I add in the benchmarking code, it stops functioning:
 
 CLKDIVbits.FRCDIV = 0;
 CLKDIVbits.PLLPRE = 1;
 PLLFBDbits.PLLFBDIV = 198;
 PLLDIVbits.POST1DIV = 4;
 PLLDIVbits.POST2DIV = 1;

 
The MCU does not function without the debugger and without the benchmarking code at 100MHz using this PLL configuration:
 
CLKDIVbits.FRCDIV = 0;
CLKDIVbits.PLLPRE = 1;
PLLFBDbits.PLLFBDIV = 200;
PLLDIVbits.POST1DIV = 4;
PLLDIVbits.POST2DIV = 1;

 
It does function at 100MHz (!!) without the debugger and benchmarking code at 100MHz using this PLL configuration:
 
 CLKDIVbits.FRCDIV = 0;
 CLKDIVbits.PLLPRE = 1;
 PLLFBDbits.PLLFBDIV = 50;
 PLLDIVbits.POST1DIV = 1;
 PLLDIVbits.POST2DIV = 1;

 
However, I am toggling a pin and it takes four times as long to toggle as it does at 99MHz.
 
It does function at 100MHz (!!) without the debugger and benchmarking code at 100MHz using this PLL configuration:
 
 CLKDIVbits.FRCDIV = 0;
 CLKDIVbits.PLLPRE = 1;
 PLLFBDbits.PLLFBDIV = 100;
 PLLDIVbits.POST1DIV = 2;
 PLLDIVbits.POST2DIV = 1;

 
However, I am toggling a pin and it takes twice as long to toggle as it does at 99MHz.
 

Now, the benchmarking code is basically a motor FOC loop using DSP instructions.  If I run at 99MHz and add a simple accumulator MPY and SACR to the main loop, the system becomes unstable:
 
volatile register int16_t aReg asm("A");
uint16_t tmp1;

aReg = __builtin_mpy(systemData.count1sec, 1024, 0, 0, 0, 0, 0, 0);
tmp1 = __builtin_sacr(aReg, 0);

 
I have had the benchmarking code running most of the time while I have been trying to get the MCU to operate at 100MHz.  So, it appears that my dsPIC33CK does in fact run at 100MHz, but only with certain PLL settings, execution is markedly slower than running at slightly slower speeds, and the DSP functions do not work properly.
 
It appears to me that to get full functionality out of my dsPIC33CK, I need to run at 95MHz.
#29
NorthGuy
Super Member
  • Total Posts : 5493
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: dsPIC33CK Fcy Frequency 2018/10/04 16:04:36 (permalink)
4 (1)
bhave
Now, the benchmarking code is basically a motor FOC loop using DSP instructions.  If I run at 99MHz and add a simple accumulator MPY and SACR to the main loop, the system becomes unstable:



Does it get hot? Someone recently posted that his dsPIC was getting very hot when running non-stop DSP commands.
#30
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/04 17:01:23 (permalink)
4 (1)
NorthGuy
Does it get hot? Someone recently posted that his dsPIC was getting very hot when running non-stop DSP commands.



I have a timer set up to run the benchmark code every second, so it is not running continuously.  The dsPIC stays slightly above ambient temperature. 
 
This timer was how I was able to tell the benchmark code was causing the problem.  It toggles a pin before and after execution.  My main loop toggles a different pin every time through the loop.  I would see the main loop toggling on my scope, then everything would stop after the benchmark toggle went high.
 
The main loop toggle is what slowed down two to four times when I did get the dsPIC to run at 100MHz Fcy.
#31
Howard Long
Super Member
  • Total Posts : 676
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/05 12:15:50 (permalink)
0
The more I think about this, the more I agree with the suggestion earlier about running from flash, and the 90MHz limitation applied to the flash only master side of the dsPIC33CH parts. The behaviour to me points to an over ambitious datasheet specification.
#32
Howard Long
Super Member
  • Total Posts : 676
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/05 14:05:12 (permalink)
0
I just tried it on a dsPIC33CK256MP505, I get an almost identical response to the OP. 90MHz works all the time, debugging or a straight program of a blinky. There's about 37mA current draw.
 
It hangs at 100MHz it's with about 17mA current draw, a straight program of the device with no debugging.
 
Debugging just doesn't work at all at 100MHz on this device once the oscillator is switched to 100MHz.
 
I can see the oscillator on the CLKO pin in all cases, but at 100MHz the processor seems to go into a reset loop at room temp, switching between FRC and PLL. If I warm it up a bit, I can get the oscillator to keep running steadily at 100MHz, but no blinky.
 
For grins I also tried this earlier on a dual core dsPIC33CH128MP502 on the master core, and overclocking to 100MHz created very similar behaviour.
 
 
 
post edited by Howard Long - 2018/10/05 14:06:31
#33
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/05 14:20:43 (permalink)
5 (1)
The dsPIC33CK MCU and peripherals are fantastic.  Using my benchmark code, even running at 90MHz (180MHz Fosc), it runs away from a Cortex-M4 running at 180MHz (executes the code 50% faster than the M4, not even counting interrupt latency).  Plus, the PWM is much more configurable and it has a much broader temperature range.  I just wish the ones I tested would actually run properly at 100MHz, since that is how it is being advertised. This makes me pause when considering it in my designs.
post edited by bhave - 2018/10/05 19:16:47
#34
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/16 09:24:08 (permalink)
0
What are the date codes for your guys' CK chips?  Maybe there was a problem with a particular production run?
 
#35
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/16 11:19:08 (permalink)
0
JimDrew
What are the date codes for your guys' CK chips?  Maybe there was a problem with a particular production run?
 




I tried two different chips.  Following are the date codes:
 
  • 1829WEV
  • 18147QR
#36
Howard Long
Super Member
  • Total Posts : 676
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/18 13:33:56 (permalink)
0
FWIW, these were the three devices I used, including the CH as well as the two CKs.
dsPIC33CH128MP502 1814 7QJ
dsPIC33CK256MP502 1814 7QH
dsPIC33CK256MP505 1813 U3C
#37
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/19 16:22:06 (permalink)
0
I wonder if its a particular combination of RAM size and package type that don't work.  It seems that some versions do work.
 
We should see what date code davekw7x has for his chip.
 
#38
davekw7x
Entropy++
  • Total Posts : 1768
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Left Coast, USA
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/19 18:41:00 (permalink)
0
JimDrew
We should see what date code davekw7x has for his chip.
 

I'm not sure what the point is, since, as the OP pointed out, I don't have the exact same device.  Mine works, his doesn't, but since the devices are different, I haven't felt that I have anything more to contribute.

But, since you asked...

dsPIC33CK256MP502: Date code 1814 7QH

Using FRC and using 8 MHz crystal, it has never hiccoughed at 100 MIPS, using the breadboard pictured in my previous post.

Also, I now have a PIM.  It has been working perfectly at 100 MIPS with FRC and with the 8 MHz crystal way down on the Explorer 16_32 main board..  The PIM has a very straightforward layout; no extravagant decoupling or exotic protection stuff.

dsPIC33CK256MP508: Date code 1814 7QS

[Edit]
Note that I have not used or attempted to use a debugger during my evaluation and preliminary development.  My test plan is, as always, with code running production builds at full speed.
 
By popular demand...
Since debugging was a sticking point for at least some people, I turned off optimization and recompiled for debugging.
Stopped before and after some floating point library calls that I put in for testing.  Results with PICkit 3 are nominal at 100 MIPS. 
 
See attachment.
[/Edit]

Regards,


Dave



post edited by davekw7x - 2018/10/19 23:26:50

Attached Image(s)


Sometimes I just can't help myself...
#39
NorthGuy
Super Member
  • Total Posts : 5493
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: online
Re: dsPIC33CK Fcy Frequency 2018/10/19 18:42:35 (permalink)
0
I had:
 
dsPIC33CK256MP502 1814 7QH - same as Howard's
dsPIC33CK128MP202 1826 HOQ
 
Both worked at 100 MHz. I didn't try to put any heavy processing on them though.
#40
Page: < 1234 > Showing page 2 of 4
Jump to:
© 2019 APG vNext Commercial Version 4.5