• AVR Freaks

Helpful ReplyHot!dsPIC33EV256GM002 Frequency Issues (PWM/TIMER)

Author
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
2020/12/02 06:57:10 (permalink)
0

dsPIC33EV256GM002 Frequency Issues (PWM/TIMER)

Hello everyone,
 
First of all I'm a beginner (well, I used to work with 16F a while back...).
So I'll try to be as clear as possible.
Setup MPLABX v5.30, xc16 v1.50, code configurator 4.0.2 (working on macOS) and a ICD4.
I'm using a custom board with a 32 MHz external oscillator. And the clock is configured to 32 MHz in MCC.
 
I started a new project and at first I had issues to get the program running without using the debug mode.
I was using the default ICD4 configuration, Auto select memories and ranges : Allow ICD 4 to Select Memories.
So I changed that to Manually select memories and ranges and I uncheked the Configuration Memory (always programmed in debug mode). And eventually the programme could run on its own.
 
But the thing is for know I'm just at the beginning and I've just implemented the PWM Module.
The issue I'm facing is when I run the program on the Debug Mode I have the correct frequency (as configured in MCC).
But when I'm in production mode (not in debug) The PWM frequency changes.
 
Example : Clock Divider 64, Master Period 0xFFFF, Master Duty Cycle 0x8000 so 131.07 ms period 50% duty cycle.
In debug mode that's what I have, but in production mode I have a 1,14 s period.
 
So I read the dsPIC33EV and the PWM datasheet but I wasn't able to figure it out where i'm screwing this up...
 
Additional test I made, was to make a LED blink using the timer (3 to be accurate) and same result I have this strange 8.7 ratio between the debug mode and the production mode.
 
So if anyone has a clue of what I'm doing wrong, your help would be much appreciated.
 
Thanks in advance for your time.
 
EDIT 03/10/2020 : Program added + external clock
 
Brice
post edited by blbdf - 2020/12/03 01:10:35
#1
du00000001
Just Some Member
  • Total Posts : 4081
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/02 08:55:29 (permalink) ☄ Helpfulby blbdf 2020/12/03 01:03:41
3.5 (2)
Check the config bits in debug vs. production more !


For me, it looks like your production code might be running with the internal FRC clock (plus an additional divide-by-2) while the debug mode might really produce the 32 MHz (MIPS).

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#2
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/02 09:17:30 (permalink)
0
Hey, thanks for your answer.
 
When I was talking about the debug mode, I'm talking about the MPLABX debugger.
As far as I know (believe) it doesn't change my configuration (does he ?!).
 
If he does, how can check the modified registers/bits ?
 
I agree with your statement, it seems that the chip is not using the External Oscillator Clock.
I've just seen a thread about someone mentionning that on some series (cannot remember which one) if there is an issue with the external clock the chip automatically relly on FRC Clock.
But when I check the clock on the input pin the signal isn't that bad (correct 32 MHz, more triangle than a perfect squarewave but I've seen worse).
 
Brice

do or do not there is no try
#3
RISC
Super Member
  • Total Posts : 5908
  • Reward points : 0
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/02 14:44:25 (permalink)
0
Hi blbdf,
Please zip and post your project (add .txt  as zip archives are not allowed as attachment).
It will be easier for forum users to help you.
There are good tutorials on MCC here : https://microchipdeveloper.com/mplabx:mcc
Regards

For support make sure to check first here : http://microchipdeveloper.com
There are hundreds of PIC, AVR, SAM...which one do YOU use ?
#4
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 01:36:43 (permalink)
0
Good Morning / Afternoon,
 
I've uploaded not directly my first program but a modified version of CE484 example which presents the same behaviour as my program.
The more it goes and the more I think du00000001 is right and in production mode the FRC clock is used (divided by 2).
But I still don't know if it's a Software mistake or a Hardware, I also posted a snapshot of the clock just measured on pin RA2...
 
The investigation continue...

do or do not there is no try
#5
du00000001
Just Some Member
  • Total Posts : 4081
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 01:46:06 (permalink)
0
Do you mind to supply a scope screenshot of the external clock?
"triangle" sounds dubious. And if the external clock is not "accepted", I think most if not all E and C class devices willl resort to the FRC clock.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#6
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 02:06:19 (permalink)
0
Hi du00000001,
 
I just did it's the DSO000001.BMP.zip.txt file. (In the original post and in theory in my previous post).
The Oscillator is : AKER S75005-32.000-X-15 (RadioSpare ref 671-9848). The "clock" trace is less than 6 mm.
 
Thanks,
 
Brice

do or do not there is no try
#7
JPortici
Super Member
  • Total Posts : 1251
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 02:51:56 (permalink) ☄ Helpfulby blbdf 2020/12/03 06:38:20
5 (1)
Clock is probably fine, probably just probed the wrong way.
 
The 33EV is one of the processors i use the most, and PWM works fine so the problem is 99% on your code.
Indeed the device will default to FRC if the primary clock is lost (and the clock monitor is enabled!)
In all my projects the device start on FRC then switch to the desired source when the clock is ready, but to do so clock switching must be enabled (and clock monitoring as well) so i will have
 
// FOSCSEL
#pragma config FNOSC = FRC              // Initial oscillator Source Selection Bits (Internal Fast RC (FRC))
#pragma config IESO = ON                // Two Speed Oscillator Start-Up Bit (Start up device with FRC,then automatically switch to user selected oscillator source)

// FOSC
#pragma config POSCMD = HS              // Primary Oscillator Mode Select Bits (HS Crystal Oscillator mode)
#pragma config OSCIOFNC = OFF           // OSC2 Pin I/O Function Enable Bit (OSC2 is clock output)
#pragma config FCKSM = CSECME           // Clock Switching Mode Bits (Both Clock Switching and Fail-safe Clock Monitor are enabled)
#pragma config PLLKEN = ON              // PLL Lock Enable Bit (Clock switch to PLL source will wait until the PLL lock signal is valid)

 
POSCMD will vary depending on if i'm using a high speed crystal, external clock or no external clock
 
then during initialization i will set up the clock as required. For example,
 
//Oscillator Configuration: 64MHz. First, switch to FRC
  __builtin_write_OSCCONH(0);
  __builtin_write_OSCCONL(OSCCON | 0x01);
  //Wait for Clock switch to occur
  while(OSCCONbits.COSC != OSCCONbits.NOSC);
  //Set up the PLL
  CLKDIVbits.PLLPRE = 0;    //PLL Input Frequency = 8/2 = 4MHz
  PLLFBD = 62;              //PLL VCO Frequency = 4 * 64 = 256MHz
  CLKDIVbits.PLLPOST = 1;   //FOSC = 256 / 4 = 64MHz, 32 MIPS
  //Switch to PRI+PLL
  __builtin_write_OSCCONH(3);
  __builtin_write_OSCCONL(OSCCON | 0x01);
  //Wait for Clock switch to occur
  while(OSCCONbits.COSC != OSCCONbits.NOSC);

 
(insert ClrWdt as required)
This board uses a 8MHz high speed crystal
 
then go on.
To check if the clock frequency is the one you want you may set up a timer interrupt

  T1CON = 0;
  T1CONbits.TCKPS = 3;  //1:256 Prescaler -> 125 kHz
  TMR1 = 0;             //Remember to Clear TMR1 because used by Bootloader
  PR1 = (FCY / (256UL * 1000)) - 1;
  T1CONbits.TON = 1;

  _T1IF = 0;
  _T1IE = 1;

 
with also defining

#define _XTAL_FREQ  8000000UL
#define FOSC        64000000UL
#define FCY         (FOSC / 2)

- Actually only FCY is required, as it can be used by some internal builtins but i prefer to define everything so i don't have to pull our the schematic everytime
 
Don't forget to enable interrupts (GIE should be set at reset but never trust init values, for example my bootloader doesn't use interrupts so GIE is cleared)
TMR1 interrupt is expected to happen at 1ms rate. flip a bit in the ISR and you should see it ON for 1ms, OFF for 1ms.
 
In short:
- Better to always have a routine to check the clock ready at hand - flipping a bit at a predetermined rate
- Check it with the internal clock, that is sure to be working (well, not. I managed to destroy the MFINTOSC on the PIC18F26K42, somehow? defective chips i guess, all from the same batch but that is like 0.00000001% chance)
- Configuration must be correct (correct clock source, correct clock type, clock switch enabled)
- Always check if the clock you want at startup is actually selected and/or switch and/or wait
EDIT:
- If you use the PLL ALWAYS switch to a non-pll source, set up the PLL, switch to a pll source
- If PLL requirements are not met the PLL will fail to switch and it will remain on the current mode, or fall back to FRC depending on clock monitor
post edited by JPortici - 2020/12/03 05:04:59
#8
du00000001
Just Some Member
  • Total Posts : 4081
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 04:13:17 (permalink)
0
blbdf
Hi du00000001,
 
I just did it's the DSO000001.BMP.zip.txt file. (In the original post and in theory in my previous post).
The Oscillator is : AKER S75005-32.000-X-15 (RadioSpare ref 671-9848). The "clock" trace is less than 6 mm.
 
Thanks,
 
Brice



Initially I missed the .BMP.
Had a look at it: what's your DSO's bandwidth? 100 MHz ?
 
Basically the waveform is looking good (when I ignore the effects of a too-low measurement bandwidth). It's just that the signal shown is a good 7 Vpp - which would make the MCU squeal if it were for real. But I assume ti's just an artifact from a too-low measurement bandwidth.
 
And be aware of the frequency limits of the PLL (input and Fsys) that differ from JPortici's values (as he obviously uses an 8 MHz quartz). Violating theses limits will most likely prevent the PLL from working correctly - eventually resulting in the fallback to FRC.
 
Are you really using the CE484 code you posted? That one was written for a DSPIC33EP256GM710. Might well be that the same Register/bit names do different things on an EV as opposed to an EP. Especially wrt the clock generation Settings (pre-/post-scaler, divider etc.).

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#9
JPortici
Super Member
  • Total Posts : 1251
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 05:12:25 (permalink)
5 (1)
i bet it's just probed with ground crocodile tip instead of ground spring tip on nearest point available.
 
Good point on the PLL settings, i forgot about that. When i say "beware about defaults" it applies to the PLL as well. The PLL settings on any reset, in the dsPIC33EV, are valid for a clock range of -whatever i can't be bothered to open the datasheet at the moment-.
The clock range includes the FRC which runs at 7.37 MHz and some other common clock frequencies (8MHz, i think 10MHz.)
Of course clocking at 32MHz violates these settings and "something" will happen
 
How the dsPIC reacts at a pll enable fail due to misconfiguration is something that is actually different between debug and run modes. don't know why.
but it may very well be the issue the op is epxeriencing
 
So, start with a non-pll source (like FRC), set up the PLL, switch to a PLL source.
#10
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 06:37:41 (permalink)
0
To du00000001 : I'm using a RSDS1152CML (RS pro) 150 MHz bandwidth.
I've checked the clock on it's own (without anything else) and I'm having the same signal.
When I use the bandwidth limitation (don't know what value) option on the scope the signal is dampened to 0.8 V to 4.2 V.
As JPortici pointed out I’m indeed using a crocodile strip.
 
Regarding the CE484 code I’ve removed the from the project the files for the dsPIC33EP. I’m just jusing the the main.c under pwm_oc_ptg.X and configured everything (SYSTEM + Pinout + PWM) using MCC.
 
To JPortici
So, if I get it right,
First: You are configuring your program to have it running using the FRC clock and then enabling the PLL.
Second: Register OSCCON, setting the bit 15 to 8 to 0 (FRC), bit 7 to 1 unchanged and bit 0 to 1 (OSWEN)
Dumb question since I cannot find the DS70580 (Oscillator Datasheet) online, why are you doing that in two steps ?
Third: Wait loop where you are checking that the current Oscillator is the one you’ve chosen (FRC)
4th: configuring your PLL to have a 64 MHz signal with your 8 MHz external oscillator
5th: Register OSCCON, setting bit 15 to 10 to 0 and 9 to 8 to 1 (Primary Oscillator with PLL) and bit 7 to 1 unchanged and bit 0 to 1 (OSWEN)
Eventually: Wait loop where you are checking that the current Oscillator is the one you’ve chosen (Primary with PLL)
 
In my case I don’t intend to use the PLL, I’ll try to implement your algorithm but I’m wondering if the chip really has an issue with my external clock will it get stuck on the last while or is the chip gonna switch to the Primary and then will get back to FRC. Guess I’ll find out soon, stay tuned I’ll be back.
 
PS: From my understanding both of you are not using MCC, I guess that was my biggest mistake, thinking I could easily setup a project using this tool without too much effort…

do or do not there is no try
#11
JPortici
Super Member
  • Total Posts : 1251
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 07:01:15 (permalink)
0
blbdf
Dumb question since I cannot find the DS70580 (Oscillator Datasheet) online, why are you doing that in two steps ?



Actually comes from DS70005144H, Register 9-1 OSCCON
https://ww1.microchip.com/downloads/en/DeviceDoc/dsPIC33EVXXXGM00X-10X-Family-Data-Sheet-DS70005144H.pdf
 
DS70580 is the oscillator chapter of the dspic33E family reference manual. You can find it in the dsPIC33EV... product page, on the documents section
direct link
https://ww1.microchip.com/downloads/en/DeviceDoc/70580C.pdf
 
In my case I don’t intend to use the PLL, I’ll try to implement your algorithm but I’m wondering if the chip really has an issue with my external clock will it get stuck on the last while or is the chip gonna switch to the Primary and then will get back to FRC. Guess I’ll find out soon, stay tuned I’ll be back.

take my code as a generic approach to the problem of setting up clocks. Try to verify if the chip is being clocked at the frequency you think it is.
 
I don't recall ever using a clock chip on this pic, only crystal and FRC so can only speculate on what the problem may be: is the clock chip actually powered from 5V? because since you probed wrong i can't tell. I expect that the dsPIC33EV need a 0-5V clock at the CLKI input (and it's very picky on voltage levels. Will not work reliably with 3.3V logic)
 
 
PS: From my understanding both of you are not using MCC, I guess that was my biggest mistake, thinking I could easily setup a project using this tool without too much effort…

and yet one has to make the extra effort, so why not ditch the libraries entirely (which may be bugged, wouldn't be the first time) and write your own code, with your own bugs?
My routines weren't hard to follow, were they?
IMHO Peripheral libraries are only a burden as they add unnecessary obfuscation and lag (with the usual exceptions of USB,Ethernet or anything that require a stack including graphics) but let's not open that can of worms again
#12
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 07:45:16 (permalink)
0
So updates:
1- I got rid off the PWM and made a LED blink using TIMER1 interrupt (1 sec occurence)
2- So it does not get stuck on the while it just get to Primary clock and then immediatly back to FRC.
I even used your modified code directly on the main loop but always get back to FRC.
 
Yes the clock is powered at 5 V and its a clean one. We have a different product with PI32MZ and a 24 MHz, and the signal is really better from what I'm looking at on this 32 MHz oscillator.
Unfortunately I don't have a lot a measurement equipments but if I can correctly observe the 24 MHz and the 32 MHz is garbage. I'm kinda blaming that damn oscillator, I'll try a different on and I'll keep you updated.
 
I agree with you, I only tried to took the "easy" way because I haven't been working on uC for over a decade now (only worked on 16F during my education and was building software from nothing everytime). And I was like "mhhhhh cool, microchip has a bunch of new features in their software why not give it a try and maybe save some time" anyway, rookie mistake...

do or do not there is no try
#13
du00000001
Just Some Member
  • Total Posts : 4081
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 08:40:17 (permalink)
4 (1)
Most likely your oscillator is ok. The culprit is the scope:
  • to well observe a signal, the scope should have the 10-fold bandwidth of the signal's basic frequency!
  • wrt the 24 MHz clock, 150 MHz is slightly beyond 6-fold: not perfect, but way better than  
  • less than 5-fold for the 32 MHz clock. Which I assume to be the reason for showing a 7 Vpp curve for an oscillator output that's powered by +5 V.
You could as well replace the 32 MHz by a 24 MHz oscillator - maybe making use of the PLL.
 
BTW: I own an EV starter kit: currently not sure whether it's running from a quartz or an external (8 MHz) oscillator, but there's hardly a need to attach anything faster as the PLL creates about any frequency you may desire to use.
 
P.S.: from time to time I make good use of MCC: even considering my efforts to somewhat "beautify" the generated code, it's a fas-track approach to get some (ds)PIC supported up and running.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#14
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/03 09:01:59 (permalink)
0
du00000001
Most likely your oscillator is ok. The culprit is the scope:
  • to well observe a signal, the scope should have the 10-fold bandwidth of the signal's basic frequency!
  • wrt the 24 MHz clock, 150 MHz is slightly beyond 6-fold: not perfect, but way better than  
  • less than 5-fold for the 32 MHz clock. Which I assume to be the reason for showing a 7 Vpp curve for an oscillator output that's powered by +5 V.
You could as well replace the 32 MHz by a 24 MHz oscillator - maybe making use of the PLL.
 
BTW: I own an EV starter kit: currently not sure whether it's running from a quartz or an external (8 MHz) oscillator, but there's hardly a need to attach anything faster as the PLL creates about any frequency you may desire to use.
 
P.S.: from time to time I make good use of MCC: even considering my efforts to somewhat "beautify" the generated code, it's a fas-track approach to get some (ds)PIC supported up and running.




I've ordered a bunch of oscillators and crystalls from different supplier and at different frequencies.
I'll see when I get them.
 
If my oscillator is fine I don't understand why the chip always switch back to FRC (even though I'm looping on setting it back to Primary)...
 
Anyway even if it is not fixed yet, thanks for your help guys(girls) you are true gentlemen(women).

do or do not there is no try
#15
blbdf
Electronic Engineer
  • Total Posts : 8
  • Reward points : 0
  • Joined: 2020/11/27 03:35:23
  • Location: France
  • Status: offline
Re: dsPIC33EV256GM002 Frequency Issues (PWM/TIMER) 2020/12/11 02:08:20 (permalink)
0
Hi folks,
 
So here are some news, I've used different clock and crystals, and still had the same issue...
So I started a brand new project without using MCC at all.
And it worked... I don't really know which setting from MCC was messing around (there was plenty compared to the ones I really had to use to get my project working).
 
Sorry for the time waste... And many thank for your support.
 
Best Regards,
 
Ps : is there a way to tag the topic as resolved ?

do or do not there is no try
#16
Jump to:
© 2021 APG vNext Commercial Version 4.5