• AVR Freaks

AnsweredHot!dsPIC33CK Fcy Frequency

Page: < 1234 > Showing page 3 of 4
Author
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/08 10:07:31 (permalink)
0
I have tried a newer dsPIC33CK64MP102 yesterday, and I couldn't debug it at 100 MHz, while it was Ok with 90 MHz. That was with my own programmer, so this cannot be related to Microchip tools. Must be a hardware issue. The stamp was 1845 S7V.
#41
du00000001
Just Some Member
  • Total Posts : 2687
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/08 11:19:41 (permalink)
0
@ NorthGuy
 
Seems you are another member of the club now  :(
 
Just some thought: where is your supply voltage? Might be a small adjustment of the supply makes a difference. But don't ask me whether lowering or raising is required: the issue might be the speed of capacitances charging/discharging vs. a small shift of the logic thresholds.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#42
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/11 12:04:53 (permalink)
0
Try using the latest IDE v5.15.
Verify reserved bits FDEVOP<9:8> are '0'.
Using any available #pragma for FDEVOP will mask these bits on older IDE versions.
#43
JimDrew
Super Member
  • Total Posts : 342
  • Reward points : 0
  • Joined: 2003/11/07 12:37:26
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/11 22:23:18 (permalink)
0
I need to try this myself on a CK part.  I have been deliberately overclocking the dsPIC33CH512MP208 chip @108MHz for the master core and 120MHz for the slave core.  It's been running 24hrs a day for several days like this and the chip is not even warm, and it's dead on for timing.  Debugging also works at this speed, using either a Pickit3 or the MPLAB ICE.   I can't imagine that the CK part (which is based on the CH) can't be overclocked in the same way (let alone run at the specified speed).
#44
bboyanov
New Member
  • Total Posts : 5
  • Reward points : 0
  • Joined: 2007/08/01 01:07:19
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 02:19:20 (permalink)
0
Hi,
I would like to share my experience with dsPIC33CK - simplest test of high MIPS test - starting with FRC and clock switching to FRCPLL.
1. Details on circuit:
dsPIC33CK128MP205 chip code 1813 U3P, 8.000 MHz crystal ( not 16MHz). 6 bypass capacitors ( 4 x 100nF + 2 x 4.7uF) on the bottom side of the module (Figure #1).
Vdd = 3.27V from LDO BA33BC0FP (external).
2. Details on code:
REFCLK output is passed to RB6 – red trace in figures below.
Scope synchro: RA3 set/clr before/after FRC-PLL activation.
WDT disabled.
// Code snippet:
// init and start REFCLK:
REFOCONH = 0x0100; // REFCLK divider = 256*2 = 512
REFOCONLbits.ROSEL = 3; // source=FRC
REFOCONLbits.ROOUT = 1;
REFOCONLbits.ROEN = 1;
Nop();
REFOCONLbits.ROSWEN = 1;
// Rem: HW: fout_REFO=15.5kHz; Theory: fout_REFO=f_FRC/(2*REFOCONH)=15.625kHz.
//
// Configure PLL prescaler, both PLL postscalers, and PLL feedback divider
CLKDIVbits.PLLPRE = 1; // N1=1
PLLFBDbits.PLLFBDIV = 192; // M=192 (96MIPS) BAD! M=180 (90MIPS) OK!
PLLDIVbits.POST1DIV = 4; // N2=4
PLLDIVbits.POST2DIV = 1; // N3=1
//
_LATA3 = 1; // Scope synchro
__builtin_write_OSCCONH((uint8_t)0x01); // FRCPLL
__builtin_write_OSCCONL((uint8_t)(OSCCONL | 1)); // OSWEN
// Wait for Clock switch to occur
while (OSCCONbits.OSWEN != 0);
//
_LATA3 = 0;
//
freq_test(); // Toggles RA1 pin to verify fcy.
//
3. Results:
3.1. Figure #2: PLLFBD = 180; (90MIPS OK!) Io = 45mA @ Vdd = 3.27V.
Blue trace = scope synchro: RA3. Red trace = REFCLK output.
fout_REFO=15.5kHz;
( Scope probe on RA1 pin confirms operation at 90MIPS. Not shown in pictures.)
3.2. Figure #3: M = 192 (96MIPS BAD!) Io = 13mA @ Vdd = 3.27V.
Blue trace = scope synchro: RA3. Red trace = REFCLK output.
Code execution crashes after clock switching to FRCPLL. REFCLK output voltage drops to 1.72V. Either decay to 2.2V or abrupt drop to 0V of RA3 voltage are observed. Then a BOR type reset occurs.
Low consumption because dsPIC mainly operates at FRC clock.
Since REFCLK output is obtained by divider from FRC, but it is badly affected by clock switching to FRCPLL in this case, possibly something wrong occurs with FRC operation ( internal LDO, power supply switches?), caused by FRCPLL at high Fvco.
Vdd is fairly clean. Generally small glitches around Vdd are observed. The biggest = 53 mV is 2.9us after the falling edge of the second REFCLK output pulse.
3.3. Figure #4: Again M = 192 (96MIPS BAD!) Io = 13mA @ Vdd = 3.27V.
Blue trace = scope synchro: RA3, Red trace = RA1 output - deliberately an offset -2V is introduced in scope.
Only the first pin toggling observed! Reset after 51.3us.
4. Attempt to overcome PLL failure by two-step clock switching ( FRC -> FRCPLL 80MIPS -> FRCPLL 96MIPS) did not succeed in the second step.
5. On similar module with dsPIC33CH128MP205 ( adapter board of the same batch) the slave core can be overclocked and works flawlessly.

I guess, the master core of dsPIC33CH is based on dsPIC33CK core, but the speed is more conservatively specified to 90MIPS, while the slave core is improved and can run faster.
Regards,
B.B.

Attached Image(s)

#45
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 09:56:23 (permalink) ☼ Best Answerby bhave 2019/05/02 10:53:09
5 (1)
B.B.,
Make sure reserved bits FDEVOP<9:8> are '0' as specified in datasheet. They must be cleared to run to 100 mips.
 
The CK and CH have some minor differences and this is one of them. Note that with CH family, FDEVOP<9:8> are reserved at '1', which is default (erased) state. 
 
Easiest fix for older IDEs (v5.10 or older) is to add any pragma for FDEVOP. like this; 
#pragma config ALTI2C1 = OFF            // Alternate I2C1 Pin bit (I2C1 mapped to SDA1/SCL1 pins)
it will apply mask found in header file
#define ALTI2C1_OFF          0xFCFF
which we see will clear bits <9:8>
 
post edited by spdmtl - 2019/04/29 13:39:06
#46
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 13:31:10 (permalink)
0
spdmtl
Make sure reserved bits FDEVOP<9:8> are '0' as specified in datasheet. They must be cleared to run to 100 mips.

 
I looked and the compiler already sets these to '0' every time.
#47
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 14:03:08 (permalink)
0
NorthGuy
I looked and the compiler already sets these to '0' every time.

How did you verify? read operation in debug mode?
The firmware in the mchp programmers is packaged with the IDE, so unless the cfg word FDEVOP is set in code, the compiler itself will not force bits 9:8 to '0'.  Your observation of running to 90 but not 100 points very much to FDEVOP<9:8>. 
Hope this helps.
#48
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 14:42:10 (permalink)
0
spdmtl
NorthGuy
I looked and the compiler already sets these to '0' every time.

How did you verify?

 
Looked at the HEX file.
 
spdmtl
The firmware in the mchp programmers ...



I haven't used Microchip programmers.
#49
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 14:59:59 (permalink)
0
NorthGuy
Looked at the HEX file.

Hmm. Hex file of what you expected to write, or a hex file from a read?
If a read, need some more info on failure details.
 
 
#50
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/29 15:35:59 (permalink)
0
spdmtl
Hmm. Hex file of what you expected to write

 
Not only the HEX file I expected to write. The HEX file I actually wrote.
 
Reading is not a problem neither:
>nsread af40 af42 -d dsPIC33CK64MP102
00af40: fffcff                      |...         |

 
Or, if you prefer:
>nsread f80036 f80038 -d dsPIC33CK64MP102
f80030:                      fffcff |         ...|

 
#51
Howard Long
Super Member
  • Total Posts : 673
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/30 09:14:07 (permalink)
0
I am sure I've missed it, but can someone point to documentation around the FDEVOP bits 8 & 9?
#52
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/30 09:31:29 (permalink) ☄ Helpfulby bboyanov 2019/05/02 23:49:31
0
FDEVOP <9:8> are documented only as 'Bit reserved, maintain as ‘0’' in the datasheet and programming specification. There is no bit name or description associated with them.
DS70005349F pg 513 TABLE 30-3
#53
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/30 12:28:00 (permalink)
0
Howard Long
I am sure I've missed it, but can someone point to documentation around the FDEVOP bits 8 & 9?



It's undocumented. The field name is MAXTEMP - "Temperature Flash Access", whatever this means.
#54
du00000001
Just Some Member
  • Total Posts : 2687
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/04/30 14:19:13 (permalink)
0
MAXTEMP - "Temperature Flash Access"  might make sense:
remember the MIPS specifications fir the dsPIC33E* architecture?
70 MIPS up to +85(?) °C - 60 MIPS beyond.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#55
Howard Long
Super Member
  • Total Posts : 673
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/05/01 14:03:52 (permalink) ☄ Helpfulby bboyanov 2019/05/02 23:51:35
5 (1)
Right. The penny has dropped. I can get the CK parts to run and debug consistently at 100 MIPS if I clear the FDEVOPT[8:9] bits.
 
In an effort to simplify my code for others to consume I only specified the minimum config bit settings. I didn't specify any bits in the FDEVOPT config register were specified. Its value was therefore always 0xFFFF.
 
Now, if I specify any one of the documented fields of FDEVOPT, the mask in the header file will implicitly also clear the undocumented bits 8 and 9.
 
So the answer is to specify at least one FDEVOPT setting in your code, even if it is the default value, as the side effect will be that bits 8 and 9 will be cleared. That allows you to run at 100 MIPS.
 
For example:
 

 
// FDEVOPT
#pragma config ALTI2C1 = OFF // Alternate I2C1 Pin bit (I2C1 mapped to SDA1/SCL1 pins)
 

 
Technically, yes, it is documented that these bits need to be zero. What's not so clear is how you achieve that though!
 
(Frustratingly, usually in my own internal code as a rule I explicitly specify all documented config bits, whether they're default or not, as it helps absolve any uncertainty. I only stripped down the config settings as a means to provide an example.)
post edited by Howard Long - 2019/05/01 14:08:38

Attached Image(s)

#56
spdmtl
New Member
  • Total Posts : 10
  • Reward points : 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/05/01 15:24:34 (permalink)
0
What version IDE? 
v5.15 and forward should clear them even without any other pragmas.
See post #46 above
 
As stated above FDEVOP<9:8> are the bits formerly referred to as MAXTEMP and control flash access timing.
Glad you got it working.
post edited by spdmtl - 2019/05/01 15:30:02
#57
dan1138
Super Member
  • Total Posts : 3105
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/05/01 16:52:49 (permalink)
0
@Howard Long,
 
Thank you for posting how you got to the bottom of this issue.
 
(With apologies to William Goldman)
So you have fallen for one of the classic blunders! The most well know is "Never get involved with a land war in Asia." only slightly less well known is "Always specify the state of every bit in every configuration word for every project every time!" :)
#58
Howard Long
Super Member
  • Total Posts : 673
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/05/02 05:07:37 (permalink)
0
spdmtl
What version IDE? 
v5.15 and forward should clear them even without any other pragmas.
See post #46 above
 
As stated above FDEVOP<9:8> are the bits formerly referred to as MAXTEMP and control flash access timing.
Glad you got it working.




It is 5.15 I'm using. If I don't specify any FDEVOPT #pragma configs, it remains at 0xFFFF. I just tried it again on another machine running 5.15, same thing.
 
You're right you did mention this in post #46, unfortunately by brain didn't compute what you were stating!
#59
NorthGuy
Super Member
  • Total Posts : 5441
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2019/05/02 06:31:13 (permalink)
0
Interesting. I always specify all config bits explicitly because I simply generate them with MPLAB X and then paste the generated text. So, I always had these bits cleared. This would explain why I could debug at 100 MHz while others couldn't.
 
However, unlike other chips, I couldn't debug dsPIC33CK64MP102 at 100 MHz, despite the bits were cleared. 90 MHz was Ok.
#60
Page: < 1234 > Showing page 3 of 4
Jump to:
© 2019 APG vNext Commercial Version 4.5