• AVR Freaks

AnswereddsPIC33CK Fcy Frequency

Page: 1234 > Showing page 1 of 4
Author
bhave
Starting Member
  • Total Posts : 27
  • Reward points : 0
  • Joined: 2018/03/15 05:33:32
  • Location: 0
  • Status: offline
2018/10/01 16:51:28 (permalink)
0

dsPIC33CK Fcy Frequency

I am evaluating the dsPIC33CK256MP506 and have been trying to obtain the 100MHz Fcy that is advertised for the MCU using the FRC oscillator.  I have it configured to start up using the FRC, then switch to the FRC with PLL.  The MCU works fantastic at 90MHz Fcy (180MHz Fosc, 360 MHz FPLLO).  As soon as I configure the PLL to output 400MHz (FPLLO), the processor is unstable and does not execute properly.  Following is the clock setup at 90MHz Fcy that works:
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 180;
    PLLDIVbits.POST1DIV = 4;
    PLLDIVbits.POST2DIV = 1;
    
    // Start clock switch to PLL
    __builtin_write_OSCCONH(0x01);
    __builtin_write_OSCCONL(0x01);
    // wait for clock switch
    while (OSCCONbits.COSC != 0x01);
    // Wait for PLL to lock
    while (OSCCONbits.LOCK != 1);

 
This 90MHz Fcy clock configuration also works properly, as documented on page 546 of the data sheet:
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 90;
    PLLDIVbits.POST1DIV = 2;
    PLLDIVbits.POST2DIV = 1;
    
    // Start clock switch to PLL
    __builtin_write_OSCCONH(0x01);
    __builtin_write_OSCCONL(0x01);
    // wait for clock switch
    while (OSCCONbits.COSC != 0x01);
    // Wait for PLL to lock
    while (OSCCONbits.LOCK != 1);

 
However, this 100MHz Fcy clock configuration fails.  This configuration is also documented in the datasheet on page 546:
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 50;
    PLLDIVbits.POST1DIV = 1;
    PLLDIVbits.POST2DIV = 1;
    
    // Start clock switch to PLL
    __builtin_write_OSCCONH(0x01);
    __builtin_write_OSCCONL(0x01);
    // wait for clock switch
    while (OSCCONbits.COSC != 0x01);
    // Wait for PLL to lock
    while (OSCCONbits.LOCK != 1);

 
This valid 100MHz Fcy clock configuration also fails:
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 200;
    PLLDIVbits.POST1DIV = 4;
    PLLDIVbits.POST2DIV = 1;
    
    // Start clock switch to PLL
    __builtin_write_OSCCONH(0x01);
    __builtin_write_OSCCONL(0x01);
    // wait for clock switch
    while (OSCCONbits.COSC != 0x01);
    // Wait for PLL to lock
    while (OSCCONbits.LOCK != 1);

 
Has anyone successfully been able to get an 100MHz Fcy using the dsPIC33CK?
 
Following is my simple test program:
 
#include <xc.h>
#include "system.h"

#pragma config FNOSC = FRC
#pragma config IESO = OFF
#pragma config POSCMD = NONE
#pragma config OSCIOFNC = ON
#pragma config FCKSM = CSECMD
#pragma config FWDTEN = ON_SW
#pragma config ICS = PGD1
#pragma config DMTDIS = OFF

SystemData systemData;

void sysInit (void)
{
    //-----------------------------------------------------
    // Configure clock - 360 MHZ -> 90 MHz Fcy
    //-----------------------------------------------------
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 180;
    PLLDIVbits.POST1DIV = 4;
    PLLDIVbits.POST2DIV = 1;
    
    // Start clock switch to PLL
    __builtin_write_OSCCONH(0x01);
    __builtin_write_OSCCONL(0x01);
    // wait for clock switch
    while (OSCCONbits.COSC != 0x01);
    // Wait for PLL to lock
    while (OSCCONbits.LOCK != 1);
    
    //-----------------------------------------------------
    // Timer 1 - use FRC @ 8MHz -> 1ms tick
    //-----------------------------------------------------
    T1CONbits.TON = 0;
    T1CONbits.TECS = 3; // use FRC
    T1CONbits.TCS = 1; // use TECS clock selection
    T1CONbits.TCKPS = 1; // /8
    TMR1 = 0;
    PR1 = 1000;
    IPC0bits.T1IP = 2; // priority 2
    IFS0bits.T1IF = 0; // clear timer1 int flag
    IEC0bits.T1IE = 1; // enable timer1 int
    T1CONbits.TON = 1; // turn on timer1
    
    INTCON2bits.GIE = 1; // global interrupt enable
    
    //-----------------------------------------------------
    // GPIO config
    //-----------------------------------------------------
    TRISBbits.TRISB6 = 0;
    LATBbits.LATB6 = 0;
    
    //-----------------------------------------------------
    // Clear global vars
    //-----------------------------------------------------
    systemData.count1sec = 0;
}

int main(void)
{

    sysInit();
    
    while (1)
    {
        if (systemData.count1sec >= 1000)
        {
            systemData.count1sec = 0;
            // toggle pin
            LATBbits.LATB6 ^= 1;
        }
    }
    
    return 0;
}

void __attribute__((__interrupt__,no_auto_psv)) _T1Interrupt(void)
{
    systemData.count1sec++;
    
    //Clear Timer1 interrupt flag
    IFS0bits.T1IF = 0;
}

 
 
EDIT: Part number is dsPIC33CK256MP506 not dsPIC33CK256MP508
post edited by bhave - 2018/10/03 18:32:09
#1
qhb
Superb Member
  • Total Posts : 9999
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/01 16:58:51 (permalink)
0
You have not mentioned what hardware you are using.
Is this an evaluation board, or your own design?
Do you have good low ESR bypass caps mounted very close to each pair of power pins?
 

Nearly there...
#2
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/01 17:05:30 (permalink)
0
Thanks for the quick reply.  This is using a QFP to dip converter board (schmartboard) and has low ESR ceramic caps as close to each power pin as possible with this sort of setup.  I am doing this with other Microchip MCUs running at similar frequencies (PIC32MK, ATSAME70J21) without any problems.
#3
du00000001
Just Some Member
  • Total Posts : 3980
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/01 17:34:53 (permalink)
0
I'm somewhat irritated: the CH's master processor is only rated for 90 MIPS and I assumed the same for the CK (which is basically a 'CH without the slave core). Might be some day we'll see a reduction in te MIPS..

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#4
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/01 17:38:14 (permalink)
0
Now that is interesting.  I did not realize the dsPIC33CH master runs at 90MHz, but the slave runs at 100MHz.  The slave runs out of RAM, right?  Maybe the flash speed is limiting the dsPIC33CK?
#5
du00000001
Just Some Member
  • Total Posts : 3980
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/01 17:46:20 (permalink)
0
The CH's slave is running from RAM.
The flash access speed is clearly the limiting factor in current MCUs, and Microchip has gotten the fastest flashes I know of.
(Other companies somewhat "cheat", often reading 4 instructions at a time from a 128 bit wide flash interface. But this trick is prone to fail when it comes to branching, calling subroutines, accessing rom variables and alike. so the dsPICs' "honest" data rate is really fast.)

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#6
JPortici
Super Member
  • Total Posts : 1175
  • Reward points : 0
  • Joined: 2012/11/17 06:27:45
  • Location: Grappaland
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/02 01:31:43 (permalink)
0
I think the dsPIC33E/C already loads two instructions at a time (48 bit). notice that the ECC flash has ECC for every pair of instructions (48 bit)
The flash is for sure 48 bits wide
From the Program Memory Reference Manual (70000613d) paragraph 7.0

When data is written to program memory, ECC generates a 7-bit Hamming code parity value for
every two (24-bit) instruction words. The data is stored in blocks of 48 data bits and 7 parity bits;

 
to the OP, i have not used the 33CK because the 33CH soon came after (and the dual core has also more peripherals, which i need) but you can test if the PLL is properly configured by useing the reference clock output. When the pll is set up wrongly weird things will happen there too
 
FVCO must be between 400MHz and 1.6GHz, in your case you are setting it at 400MHz.
If instead of doing this
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 50;
    PLLDIVbits.POST1DIV = 1;
    PLLDIVbits.POST2DIV = 1;

 
you do this
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 100;
    PLLDIVbits.POST1DIV = 2;
    PLLDIVbits.POST2DIV = 1;

 
does the situation improve?
post edited by JPortici - 2018/10/02 01:36:59
#7
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/02 04:02:14 (permalink)
0
JPortici - I am not in the office today and will test your suggestion tomorrow.  I did test at both ends of the PLL frequency range without success (FVCO of 400MHz and 1600MHz),  but did not test the middle of the range:
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 50;
    PLLDIVbits.POST1DIV = 1;
    PLLDIVbits.POST2DIV = 1;

 
and 
 
    CLKDIVbits.FRCDIV = 0;
    CLKDIVbits.PLLPRE = 1;
    PLLFBDbits.PLLFBDIV = 200;
    PLLDIVbits.POST1DIV = 4;
    PLLDIVbits.POST2DIV = 1;

 
#8
Howard Long
Super Member
  • Total Posts : 836
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/02 07:59:41 (permalink)
0
I agree with the OP, my initial indications show that the device doesn't seem to work at 100MIPS in my tests, but it does at 90MIPS.
 
I am using a dsPIC33CK256MP502 on a breakout board mounted on solderless breadboard. Three 100nF caps, one on each of the three power pin pairs as close as I can get them. 10k pullup on MCLR. I'm out in the field at the moment, so don't have proper lab gear. I tried it with both a PICKIT3 and ICD3, powered from the debuggers. It might still be a power supply related problem but I'm not in a position right now to try that.
 
The debugger and CPU seem to stop talking, I have to restart MPLAB X and plug/unplug the debugger to get going again.
 


// DSPIC33CK256MP502 Configuration Bit Settings
// FOSCSEL
#pragma config FNOSC = FRCDIVN // Oscillator Source Selection (Internal Fast RC (FRC) Oscillator with postscaler)
#pragma config IESO = OFF // Two-speed Oscillator Start-up Enable bit (Start up with user-selected oscillator source)
// FOSC
#pragma config POSCMD = NONE // Primary Oscillator Mode Select bits (Primary Oscillator disabled)
#pragma config OSCIOFNC = OFF // OSC2 Pin Function bit (OSC2 is clock output)
#pragma config FCKSM = CSECMD // Clock Switching Mode bits (Clock switching is enabled,Fail-safe Clock Monitor is disabled)
#pragma config PLLKEN = ON // PLL Lock Status Control (PLL lock signal will be used to disable PLL clock output if lock is lost)
#pragma config XTCFG = G3 // XT Config (24-32 MHz crystals)
#pragma config XTBST = ENABLE // XT Boost (Boost the kick-start)
// FWDT
#pragma config WINDIS = OFF // Watchdog Timer Window Enable bit (Watchdog Timer operates in Window mode)
#pragma config FWDTEN = ON_SW // Watchdog Timer Enable bit (WDT controlled via SW, use WDTCON.ON bit)
// FICD
#pragma config ICS = PGD1 // ICD Communication Channel Select bits (Communicate on PGEC1 and PGED1)
#pragma config JTAGEN = OFF // JTAG Enable bit (JTAG is disabled)
#include <xc.h>
#define FCY 100000000
#include <libpic30.h>
int main(void)
{
TRISA=0;
TRISB=0;
LATA=0;
LATB=0;

// Configure PLL prescaler, both PLL postscalers, and PLL feedback divider
CLKDIVbits.PLLPRE = 1; // N1=1 => div-by-1
// PLLFBDbits.PLLFBDIV = 125; // M = 125
// PLLDIVbits.POST1DIV = 5; // N2=5 (div-by-5)
// PLLFBDbits.PLLFBDIV = 90; // M = 90
PLLFBDbits.PLLFBDIV = 100; // M = 100
// PLLDIVbits.POST1DIV = 4; // N2=4 (div-by-4)
PLLDIVbits.POST1DIV = 2; // N2=2 (div-by-2)
PLLDIVbits.POST2DIV = 1; // N3=1 (div-by-1)
// Initiate Clock Switch to FRC with PLL (NOSC=0b001)
__builtin_write_OSCCONH(0x01);
__builtin_write_OSCCONL(OSCCON | 0x01);
// Wait for Clock switch to occur
while (OSCCONbits.OSWEN!= 0);

while (1)
{
__delay_ms(5000);
Nop();
Nop();
Nop();
Nop();
Nop();
Nop();
}
return 0;
}

#9
NorthGuy
Super Member
  • Total Posts : 6350
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/02 09:15:52 (permalink)
0
I had it working at 100 MHz (it was CK128MP202 as I recall) with the same 100/2/1 setup as Howard's and with nearly identical code (except I set the whole CLKDIV to 1 and don't "or" with OSCCON in __builtin_write_OSCCONL. I also started from FRC, not from FRCDIV).  Debugging worked too.
 
As to the CH slave. Since it runs from RAM, it has different instruction timing. For example, jumps take 2 cycles instead of 4. So, in practical terms it can work faster than the master (and faster than CK).
#10
davekw7x
Entropy++
  • Total Posts : 1891
  • Reward points : 0
  • Joined: 2012/01/16 12:01:07
  • Location: Second star on the right, straight on till morning
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/02 09:43:19 (permalink)
0
I have no problems running my dsPIC33CK256MP502 at 100 MIPS using the 8 MHz internal FRC or an 8 MHz crystal on my solderless breadboard.

I always start with FRC and change to FRCPLL or PRIPLL in an initialization function

Clock-related configuration settings:
Start with FNOSC = FRC
I enable POSCMD so that I can use the crystal if I want to

#pragma config FNOSC = FRC              // Oscillator Source Selection (Internal Fast RC (FRC))
#pragma config IESO = ON                // Two-speed Oscillator Start-up Enable bit (Start up device with FRC, then switch to user-selected oscillator source)

// FOSC
#pragma config POSCMD = XT              // Primary Oscillator Mode Select bits (XT Crystal Oscillator Mode)
#pragma config OSCIOFNC = OFF           // OSC2 Pin Function bit (OSC2 is clock output)
#pragma config FCKSM = CSECME           // Clock Switching Mode bits (Both Clock switching and Fail-safe Clock Monitor are enabled)


Clock initialization code.  Here I show FRCPLL, but more usual operation is PRIPLL

    // PLL input is 8 MHz
    // PLL output is 8 MHz * M / (N1*N2*N3) = 8 MHz * 200 / (1*4*1) = 400 MHz
    // So Fosc = 200 MHz
    //    FCY  = 100 MIPS
    //
    // 0x3001 is default, so this may not be strictly necessary
    CLKDIV = 0x3001;    // PLLPRE 1:1 ==> N1 = 1
    PLLFBD = 200;       // M = 200
    // 0x41 is default, so this may not be strictly necessary
    PLLDIV = 0x41;      // PLLPOST1 1:4 ==> N2 = 4
                        // PLLPOST2 1:1 ==> N3 = 1
    
    //__builtin_write_OSCCONH((uint8_t)0x03);          // PRIPLL
    __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)
        {}



For preliminary testing Main.c had the following:

// Configuration pragmas are in their own separate .c file

#include <xc.h>
// Define FCY so that __delay_ms() can be used.
// Observe LED blinking at 1 Hz interval to verify the actual operating frequency
#define FOSC 200000000UL
#define FCY ((FOSC+1) / 2)
#include <libpic30.h>

int main()
{
    //Initialize clock, I/O, timers, uart, etc.
    // Note that timer interrupt is used to toggle
    // LED2 at 1 millisecond intervals
    init_system();
    
    __delay_ms(100); // Give things a little time to settle down
    printf("\nCompiled on %s at %s PDT by XC16 version %u\n",
            __DATE__, __TIME__, __XC16_VERSION);
    
    printf("OOSCCON = 0x%04X, FCY = %lu\n", OSCCON, FCY);
    while (1) {
        LED1_Toggle();
        __delay_ms(1000);
    }


Output

Compiled on Oct  2 2018 at 08:57:21 PDT by XC16 version 1035
OOSCCON = 0x1120, FCY = 100000000

And the LED is toggling at 1 second intervals.
 
Bottom line: If these settings don't work for you, I would say that the problem is in your hardware.  Some considerations:
  • Inadequate decoupling: Deficient capacitor characteristics or caps not close enough to MPU pins?
  • Power not clean.  Maybe bulk decoupling required?
  • Noise pickup from floating pins or from "skywire" jumpers on breadboard?

Regards,

Dave



post edited by davekw7x - 2018/10/02 10:51:22

Attached Image(s)


Sometimes I just can't help myself...
#11
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/02 17:03:45 (permalink)
0
NorthGuy and davekw7x - Thanks for confirming that your dsPIC33CK's worked at 100MHz and posting the clock configurations that were successful.  I will double check my hardware setup and report back.
#12
Howard Long
Super Member
  • Total Posts : 836
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 01:06:36 (permalink)
0
I just retried it, with the settings suggested by others, (FRC, PRE = div-by-1, FBDIV = div-by-200, POST1DIV = DIV-by-4, POST2DIV = div-by-1) and I have the same problem.
 
The oscillator switches, and I can do some processing. If I place a breakpoint, or try to use any debugging functions after the clock switch, it crashes, often with the error below. I have to restart MPLAB X and unplug/plug in the debugger (ICD3).
 

Failed while sending cmd_SET_PERIPHERAL_FREEZE command
An Error occurred while running
Reception on endpoint 1 failed (err = -10121)

#13
Howard Long
Super Member
  • Total Posts : 836
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 12:56:35 (permalink)
0
By way of an update...
 
I'm back in the lab, and took the opportunity to (a) solder 0805 10nF caps on the breakout board within 5mm of the device's pins, (b) add an on board 3.3V LDO powered from a lab power supply, and (c) add an LED + 220 ohm resistor for a blinky for timing purposes.
 
In short, I still have a similar problem to the OP.
 
Although I can get the device to work reliably at 100MIPS when programmed, it will not debug even close to reliably at that speed: when I was out in the field, I didn't have any method of determining the speed other than to manually time breakpoints with a debugger. It will single step, but if I set it off running after a breakpoint, it crashes and I have to restart MPLAB X and re-insert the debugger.
 
Dropping the speed to 90MHz, no problem.
 
 
I've tried ICD3, PICKIT3, and RealICE, it's the same behaviour.
 
I sometimes get one of the following errors after several seconds, although sometimes it just hangs:
 
Failed while sending cmd_SET_PERIPHERAL_FREEZE command
An Error occurred while running
Reception on endpoint 1 failed (err = -10121)
 
Or
 
Reception on endpoint 1 failed (err = -10121)
Failed while stepping the target
Failed reading bulk data (memory type 12, address 28
Reception on endpoint 1 failed (err = -10121)
Failed reading bulk data (memory type 12, address 4120
Transmission on endpoint 2 failed
Failed reading bulk data (memory type 12, address 28
Transmission on endpoint 2 failed
Failed reading bulk data (memory type 12, address 4120
Transmission on endpoint 2 failed
 
It's the same behaviour with MPLAB X 4.20, 5.00, 5.05.
 
For reference, current draw is ~44mA when running, so beware of trying to power  from a PICKIT3 at this speed, which current limits at about 30mA.
 
Another data point, I only seem to be able to use hardware breakpoints on this device, software breakpoints don't (yet) seem to be supported.
 

 
 
 

// DSPIC33CK256MP502 Configuration Bit Settings
 
 
 
// FOSCSEL
#pragma config FNOSC = FRCDIVN // Oscillator Source Selection (Internal Fast RC (FRC) Oscillator with postscaler)
#pragma config IESO = OFF // Two-speed Oscillator Start-up Enable bit (Start up with user-selected oscillator source)
// FOSC
#pragma config POSCMD = NONE // Primary Oscillator Mode Select bits (Primary Oscillator disabled)
#pragma config OSCIOFNC = OFF // OSC2 Pin Function bit (OSC2 is clock output)
#pragma config FCKSM = CSECMD // Clock Switching Mode bits (Clock switching is enabled,Fail-safe Clock Monitor is disabled)
#pragma config PLLKEN = ON // PLL Lock Status Control (PLL lock signal will be used to disable PLL clock output if lock is lost)
 
 
 
// FWDT
#pragma config WINDIS = OFF // Watchdog Timer Window Enable bit (Watchdog Timer operates in Window mode)
#pragma config FWDTEN = ON_SW // Watchdog Timer Enable bit (WDT controlled via SW, use WDTCON.ON bit)
 
 
 
// FICD
#pragma config ICS = PGD1 // ICD Communication Channel Select bits (Communicate on PGEC1 and PGED1)
#pragma config JTAGEN = OFF // JTAG Enable bit (JTAG is disabled)
 
 
 
#include <xc.h>
#define FCY 100000000
#include <libpic30.h>
 
 
 
int main(void)
{
TRISA=0;
TRISB=0;
LATA=0;
LATB=0;

RCON=0;

// Configure PLL prescaler, both PLL postscalers, and PLL feedback divider
CLKDIVbits.PLLPRE = 1; // N1=1 => div-by-1
PLLFBDbits.PLLFBDIV = 180; // M = 180
// PLLFBDbits.PLLFBDIV = 200; // M = 200
PLLDIVbits.POST1DIV = 4; // N2=4 (div-by-4)
PLLDIVbits.POST2DIV = 1; // N3=1 (div-by-1)
__builtin_write_OSCCONH(0x01);
__builtin_write_OSCCONL(OSCCON | 0x01);
while (OSCCONbits.OSWEN!= 0);

while (1)
{
Nop();
Nop();
Nop();
Nop();
Nop();
Nop();
 
 
 
LATBbits.LATB5=1;
Nop();
Nop();
Nop();
Nop();

__delay_ms(250);
Nop();
Nop();
Nop();
Nop();
 
 
 
LATBbits.LATB5=0;
Nop();
Nop();
Nop();
Nop();

__delay_ms(250);
 
 
 
Nop();
Nop();
Nop();
Nop();
Nop();
Nop();
}
return 0;
}
 
 
 

post edited by Howard Long - 2018/10/03 13:27:17

Attached Image(s)

#14
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 12019
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 13:54:19 (permalink)
0
Failed while sending cmd_SET_PERIPHERAL_FREEZE command

 
I get these regularly even on an old PIC24E @ 60 MIPS.  It seems to be a common issue with the enhanced 16-bit core.
#15
du00000001
Just Some Member
  • Total Posts : 3980
  • Reward points : 0
  • Joined: 2016/05/03 13:52:42
  • Location: Germany
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 13:58:44 (permalink)
0
@ Howard Long
10 nF might be too small - recommendation is 100(+) nF!
 
More important:I would never route the debug interface via such a breadboard: too much capacitance vs. adjacent lines, badly definned resistances (increasing with age) etc.  All sorts of problems with this interface increase with frequency.

PEBKAC / EBKAC / POBCAK / PICNIC (eventually see en.wikipedia.org)
#16
Howard Long
Super Member
  • Total Posts : 836
  • Reward points : 0
  • Joined: 2005/04/04 08:50:32
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 15:20:23 (permalink)
0
du00000001
@ Howard Long10 nF might be too small - recommendation is 100(+) nF! More important:I would never route the debug interface via such a breadboard: too much capacitance vs. adjacent lines, badly definned resistances (increasing with age) etc.  All sorts of problems with this interface increase with frequency.


There are also 100nF on the breadboard fwiw, the 10nF reel happened to be on the bench. I can switch them but I really doubt it’ll make any difference.

Regarding the debug header stuff, I also ran my very short 1” debug cable to the device, still identical behaviour. I’m now reasonably satisfied there is a problem with the debug interface, but it’s in the debugger firmware. I’ve run this kind of interface for years on breadboard including PIC32MZ on breakouts at 252MHz, no problem.

The basic 5 pin ICD debug interface doesn’t operate anywhere near the device frequency, it tops out at about 3MHz clock. PGC and PGD look fine on the scope (Keysight MSO7104B, 1GHz BW with 1130A 1.5Ghz FET probes). If there was a signal integrity problem, I would expect behavior to change depending on Vdd (I have tested this behaviour from 3.0 to 3.6V) and debugger i/f cable length, but it doesn’t.
#17
NorthGuy
Super Member
  • Total Posts : 6350
  • Reward points : 0
  • Joined: 2014/02/23 14:23:23
  • Location: Northern Canada
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 16:11:04 (permalink)
0
du00000001
More important:I would never route the debug interface via such a breadboard: too much capacitance vs. adjacent lines, badly definned resistances (increasing with age) etc.  All sorts of problems with this interface increase with frequency.



Breadboards are absolutely fine at these speeds (and at higher speeds too). I wish my breadboards were as neat as theirs, but still everything is working fine. It's CH on the picture, but CK worked fine at 100 MHz in this setting:
 

 
#18
qhb
Superb Member
  • Total Posts : 9999
  • Reward points : 0
  • Joined: 2016/06/05 14:55:32
  • Location: One step ahead...
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 16:25:32 (permalink)
0
Strange, Firefox won't display your photo at
https://www.northernsoftware.com/forum/33ch.jpg
 

An error occurred during a connection to www.northernsoftware.com. The peer used an unsupported combination of signature and hash algorithm. Error code: SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM

Works ok in Chrome though.
 

Nearly there...
#19
jtemples
عُضْوٌ جَدِيد
  • Total Posts : 12019
  • Reward points : 0
  • Joined: 2004/02/13 12:31:19
  • Location: Southern California
  • Status: offline
Re: dsPIC33CK Fcy Frequency 2018/10/03 16:51:52 (permalink)
0
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"
#20
Page: 1234 > Showing page 1 of 4
Jump to:
© 2020 APG vNext Commercial Version 4.5