dsPIC33CK 200 MHz / 100 Mips settings

[diebobo]

Hi Les,

I think i got the bugger working at 200 Mhz. A post on the Microchip forum ( https://www.microchip.com/forums/m1069904.aspx ) got me searching in the right direction. They are talking about 2 un-documented bits which need to remain 0 in the config ( FDEVOP<9:8> )

I checked the default config of FDEVOPT and this whas

Code Select Expand

Config FDEVOPT  = ALTI2C1_OFF, ALTI2C2_OFF, ALTI2C3_OFF, SMBEN_STANDARD, SPI2PIN_PPS
This creates a HEX value : 0xFBFF which is in binary : 1111101111111111 .. you can see that bit 8 and 9 are set, which the datasheet tells to mantain as 0

I altered the bin value to : 1111100011111111, so this gets you the same options as before only difference is bit 8 and 9 are cleared so a 0. This is Hex 0xF8FF. So that code part becomes :

Code Select Expand

Config FDEVOPT  = 0xF8FF ''ALTI2C1_OFF, ALTI2C2_OFF, ALTI2C3_OFF, SMBEN_STANDARD, SPI2PIN_PPS

The code to set the clockspeed settings become :

Code Select Expand

    CLKDIV = $3001          ' FRCDIV FRC/1, PLLPRE 1, DOZE 1:8
    PLLFBD = 100 ''90
    OSCTUN = $00
    PLLDIV = $21            ' POST1DIV 1:2, VCODIV FVCO/4, POST2DIV 1:1
    ACLKCON1 = $0101        ' FRCSEL FRC, APLLPRE 1:1
    APLLFBD1 = $C8
    APLLDIV1 = $42          ' APOST1DIV 1:4, APOST2DIV 1:2, AVCODIV FVCO/4*)

    Write_OSCCONH($01)
    Write_OSCCONL($01)

    While OSCCONbits_OSWEN <> 0 : Wend  ' Wait for the clock switch to occur
This ( and offcourse change Declare Xtal = 200 ) seems to work for me. A test delay 500ms checked with logic analyzer = 501ms and a serial connection of 115200 seems 30 min stable..

So 2 question, can you confirm my results and if yes then we do we need an extra config part / name for FDEVOPT or do you make changes so that theese bits are always cleared regardless of the configs ?

Bob

[top204]

Nicely done Bob. Maybe this is what is stopping the devices operating successfully beyond 180MHz as well. It's handy that I allowed a constant value as well to follow the config name isn't it? I've had this type of issue with 8-bit devices over the years, so I made it so a user could calculate what should be in the config cell and place it there as a constant.

So even the techs in Microchip do not fully undestand how these new devices of theirs actually work, or most probably, it is an errata. :-)

The config fuse names and values are taken directly from the Microchip XML files by the PPI creator program, so I'll see if I can adjust the values associated with the FDEVOPT config area. As you know, 'Anding' clears bits, so I'll see what I can do. Maybe make sure bits 8 and 9 of the values are always clear in the fuse values associated with that config cell.

The fuse names and values are at the end of a device's .ppi file.

Clearing the FDEVOPT flash memory area is not something I would do within the compiler itself automatically, because it could cause problems down the line, and things like that are down to the user only. Erasing a device fully while programming will clear these parts of flash memory, so the 'Anding' should clear the appropriate bits, because an erased cell holds $FFFF.

[charliecoutas]

Well done Bob, but DEVOPT is only used for SPI, isn't it? I don't see how this could affect the main clock speed setting.
I will try it tomorrow on my setup; 200MHz would be a useful speed if it is reliable.

Charlie

[charliecoutas]

Now I understand, ignore my last post. My chip runs OK at 200MHz with this mod in, thanks Bob, Les.

[top204]

Niiiiiiiiiice!

I've ran tests and Bob's findings of the Microchip mistake has turned out excellently. With bits 8 and 9 cleared, 200MHz with the internal oscillator works flawlessly on my 'Positron16' board that was having difficulties above 170MHz. :-) Many thanks Bob.

I've gone into the device's (dsPIC33CK128MP202) ppi file and changed the fuse values to:

Code Select Expand

;----- FDEVOPT (0x15f40) --------------------------------------------------
ALTI2C1_ON =     0xFCF7     ; I2C1 mapped to ASDA1/ASCL1 pins
ALTI2C1_OFF =    0xFCFF     ; I2C1 mapped to SDA1/SCL1 pins
ALTI2C2_ON =     0xFCEF     ; I2C2 mapped to ASDA2/ASCL2 pins
ALTI2C2_OFF =    0xFCFF     ; I2C2 mapped to SDA2/SCL2 pins
ALTI2C3_ON =     0xFCDF     ; I2C3 mapped to ASDA3/ASCL3 pins
ALTI2C3_OFF =    0xFCFF     ; I2C3 mapped to SDA3/SCL3 pins
SMBEN_STANDARD = 0xF8FF     ; Standard I2C input threshold operation
SMBEN_SMBUS =    0xFCFF     ; SMBus input threshold is enabled
SPI2PIN_DEDICATED =0xDCFF   ; SPI2 uses dedicated I/O pins
SPI2PIN_PPS =    0xFCFF     ; SPI2 uses I/O remap (PPS) pins

Notice the hex values all have bits 8 and 9 cleared now.

I'll go through the other dsPIC33xxCK .ppi files and change them, first making sure they are all using the same values for the fuses, because you can never tell with Microchip. ;-)

The code I used for the test is listed below... Notice the Baud rate of "921600"... Yes, that's correct, "921600". And that is fast!!!

Code Select Expand

'
'   /\\\\\\\\\
'  /\\\///////\\\
'  \/\\\     \/\\\                                                 /\\\          /\\\
'   \/\\\\\\\\\\\/        /\\\\\     /\\\\\\\\\\     /\\\\\\\\   /\\\\\\\\\\\  /\\\\\\\\\\\  /\\\\\\\\\
'    \/\\\//////\\\      /\\\///\\\  \/\\\//////    /\\\/////\\\ \////\\\////  \////\\\////  \////////\\\
'     \/\\\    \//\\\    /\\\  \//\\\ \/\\\\\\\\\\  /\\\\\\\\\\\     \/\\\         \/\\\        /\\\\\\\\\\
'      \/\\\     \//\\\  \//\\\  /\\\  \////////\\\ \//\\///////      \/\\\ /\\     \/\\\ /\\   /\\\/////\\\
'       \/\\\      \//\\\  \///\\\\\/    /\\\\\\\\\\  \//\\\\\\\\\\    \//\\\\\      \//\\\\\   \//\\\\\\\\/\\
'        \///        \///     \/////     \//////////    \//////////      \/////        \/////     \////////\//
'                                  Let's find out together what makes a PIC Tick!
'
' Test a dsPIC33CK device operating at 200MHz with its internal oscillator.
' By continuously transmitting text at a very high Baud rate
'
    Device = 33CK128MP202
    Declare Xtal = 200
'
' USART1 setup
'
    Declare Hserial_Baud = 921600
    Declare HRSOut1_Pin = PORTB.0
'
' PPS output defines for a dsPIC33CK128MP202 device
'
$define PPS_OutPin_RB0  cOut_Pin_RP32
$define PPS_OutPin_RB1  cOut_Pin_RP33
$define PPS_OutPin_RB2  cOut_Pin_RP34
$define PPS_OutPin_RB3  cOut_Pin_RP35
$define PPS_OutPin_RB4  cOut_Pin_RP36
$define PPS_OutPin_RB5  cOut_Pin_RP37
$define PPS_OutPin_RB6  cOut_Pin_RP38
$define PPS_OutPin_RB7  cOut_Pin_RP39
$define PPS_OutPin_RB8  cOut_Pin_RP40
$define PPS_OutPin_RB9  cOut_Pin_RP41
$define PPS_OutPin_RB10 cOut_Pin_RP42
$define PPS_OutPin_RB11 cOut_Pin_RP43
$define PPS_OutPin_RB12 cOut_Pin_RP44
$define PPS_OutPin_RB13 cOut_Pin_RP45
$define PPS_OutPin_RB14 cOut_Pin_RP46
$define PPS_OutPin_RB15 cOut_Pin_RP47
'
' Create a variable for the test
'
    Dim dCounter As Dword
   
'----------------------------------------------------------------------------------
' The main program starts here
'
Main:
    IntOsc_200MHz()                                 ' Setup the device to operate at 200MHz

    PPS_Unlock()                                    ' Unlock the PPS peripheral
    PPS_Output(PPS_OutPin_RB0, cOut_Fn_U1TX)        ' Set the appropriate PPS pin for the USART1 peripheral TX

    dCounter = 0                                    ' Clear the counter variable before the loop begins
    Do                                              ' Create a loop
        HRSOutLn Dec9 dCounter, ": Thanks Bob"      ' Transmit to a serial terminal
        Inc dCounter                                ' Increment the counter
        DelayMS 10                                  ' Give a little time for a serial terminal to recover
    Loop                                            ' Do it forever

'----------------------------------------------------------------------------------
' Setup the device to operate at 200MHz with its internal oscillator
' Input     : None
' Output    : None
' Notes     : Waits for the oscillator to become stable
'
Proc IntOsc_200MHz()
    CLKDIV   = %0011000000000001                         
    PLLFBD   = 100                          ' PLL Feedback 1:100
    OSCTUN   = $00
    PLLDIV   = %0000000000100001                          
    ACLKCON1 = $0101                       
    APLLFBD1 = $C8
    APLLDIV1 = %0000000001000010                        
    Write_OSCCON($0101)
    While OSCCONbits_OSWEN <> 0 : Wend      ' Wait for the clock switch to occur
    While OSCCONbits_LOCK <> 1 : Wend       ' Wait for the oscillator to lock
EndProc

'----------------------------------------------------------------------------------
' Set the fuses for internal oscillator on a dsPIC33CK128MP202 device
'
    Config FSEC     = BWRP_OFF, BSS_DISABLED, BSEN_OFF, GWRP_OFF, GSS_DISABLED, CWRP_OFF, CSS_DISABLED, AIVTDIS_OFF
    Config FOSCSEL  = FNOSC_FRC, IESO_OFF
    Config FOSC     = POSCMD_NONE, OSCIOFNC_ON, FCKSM_CSECMD, PLLKEN_OFF, XTCFG_G0, XTBST_ENABLE
    Config FWDT     = SWDTPS_PS2147483648, RCLKSEL_LPRC
    Config FPOR     = BISTDIS_DISABLED
    Config FICD     = ICS_PGD1, JTAGEN_OFF, NOBTSWP_DISABLED
    Config FDMT     = DMTDIS_OFF
    Config FDEVOPT  = ALTI2C1_ON, ALTI2C2_ON, ALTI2C3_ON, SMBEN_STANDARD, SPI2PIN_PPS
    Config FALTREG  = CTXT1_OFF, CTXT2_OFF, CTXT3_OFF, CTXT4_OFF

The code above has the fuse value changes made in the PPI file, so I will change them all and create an update for them ASAP. Notice that the code now allows the line:

While OSCCONbits_LOCK <> 1 : Wend

to work, because before the Microchip mistake correction, it would not always leave the loop because the oscillator's PLL was not always locking at high frequencies. :-)

Below is a screenshot of the above program working on the serial terminal I created for my Amicus18 board.

[charliecoutas]

Good work Les and Bob, much appreciated.

Charlie

[diebobo]

Ahh Yeahh ... Good to see they are also working on your side !.. Left mine running at 200 overnight and no hickups or whatever.. Just did a test how far i can push it, is a short test it could do 230 and still have reliable comms at 115200. For now ill just stick to 200 .. Thanks for incoming updates Les.. Can i ask for another update ? Please add the SPI ports ( like cOut_Fn_SDO1 ) in the def files. They are missing

[John Lawton]

It certainly looks like a nice, fast device, and with 8 PWM outputs would have been handy for a previous project, oh well...

[top204]

I'll hunt them out from the Microchip XML files, if they are there, and place them in the ppi and def files. If not in there, which is a common occurance now, I'll go through the datasheets for their values.

This has put new blood through my veins and given me hope for my Positron16 board and some, really, nice projects. i.e. True 6502 microprocessor and SID emulator, with filters. 24-bit ADC and DAC, digital audio projects etc.....

[diebobo]

Well, thoose kind of projects will certainly keep you occupied in the upcoming holliday season.. At least the full 100 mips is unlocked at moment, that won't be holding you down anymore

[Dompie]

Les, are you planning to sell your Positron16 boards?
I would be very interested.

Johan

[top204]

Les, are you planning to sell your Positron16 boards?

If I can find the time to create a bootloader for it and the documentation etc...

My holiday season will be filled with getting the new 8-bit 18F devices into the compiler, because they operate with a different assembler that is absolutely dreadful and requires different assembler directives and "must" use a linker, "for some inexplicable reason", and gives totally different listings back, so I have to write a new parser for the optimiser. The assembler and linker parts are complete, but the optimiser is complex because it looks at the assembler's .lst code for "peep-hole" optimisation, but the linker does not create a .lst file, and the assembler's .lst file is not final because it is the linker that adds the address'. Also, the .lst file has a lot of the code that is not in flash memory, missing, so I will have to fill that in for the optimiser as well because these directives hold variables, constants and fuses etc...

Bob... I remember looking at that forum thread on the Microchip forum a few months back, concerning the 100 MIPS problem, but I got so bored and frustrated reading all the nonsense in it, I never got to the end of it, so I missed the important part. Well done for persevering with the nutters on it. :-)

I have always been an advocate of "If you do not know the correct answer to a question asked of you, say so, and do not make things up to make you seem intelligent" :-) That's why I am not a rich person, because I do not spout crap and I do not have an, over inflated, Ego. These things seem to be the number one factor in becoming rich or famous these days, unfortunately. ;-)

[charliecoutas]

I think it would be wise to mention a problem I had getting the dsPIC33CK256MP505 to do anything at all:

The compiler sets all the analog/digital port pins to analog, and I wrongly assumed that they would all be digital. It took me quite a while to work this out.  The assembler shows this, where a "1" means "ANALOG":

    setm.w ANSELA
    setm.w ANSELB
    setm.w ANSELC
    setm.w ANSELD

Is that what you intended Les?

Charlie

[top204]

Whoops.... Sorry.

The dsPIC33CK devices seem to have reversed the bits in the ANSELx SFRs compared to some other devices. Why do they keep doing this sort of thing in their devices ? Why can't they keep standards? Some devices require low bits for analogue and some device's require high bits for analogue... I'll never understand what goes on in the Microchip, third party, overseas, design departments. They seem to make things up as they go along!!!!

I have updated .ppi and .def files for the dsPIC33CK devices coming up, so I'm so glad you spotted the problem before I created the update installer.


Open the device's .def file and at the bottom you will see:

'
'----------------------------------------------------------------------------------
' Make analogue pins digital
' This section may be added too for extra SFRs
'
#IfnSym __SYSCOM_LIBRARY_OFF_      ' Has the library been disabled in the compiler?
ANSELA = $FFFF
ANSELB = $FFFF
ANSELB = $FFFF

etc....

Change these to:
'
'----------------------------------------------------------------------------------
' Make analogue pins digital
' This section may be added too for extra SFRs
'
#IfnSym __SYSCOM_LIBRARY_OFF_      ' Has the library been disabled in the compiler?
ANSELA = 0
ANSELB = 0
ANSELC = 0

etc...

These are created automatically from the Microchip XML and PIC files, and some .def files seem OK, while others have them set to $FFFF, so I think some of the XML files have been incorrect.

[charliecoutas]

Thanks Les. It seems totally stupid for Microchip to reverse the meaning of some bits like that. I am making progress with the pulse generator but am now having trouble getting UART1 to work. I tried your demo code but couldn't get that to work either. I'll start a new thread:

Charlie

[JimDrew]

This was documented by Microchip in the original datasheets, and later revised.  We talked about this back in 2019 in the Microchip forum (post you linked to above), with this critical info you need to pay attention to because there was a difference between the CH and CK defines:

https://www.microchip.com/forums/FindPost/1096364

I have been running CH parts at 108MHz/120MHz and CK parts at up to about 128MHz for days at a time.  So, there is clearly some headroom in the design.

[trastikata]

I can report that dsPIC33EP256MU806 runs at 180 MHz - 90 MIPS with no glitches so far!

[John Lawton]

Nice. What are you using it for?

[trastikata]

Nice. What are you using it for?

For the moment I am just getting familiar with this PIC and testing code for all modules of interest.

The aim is to use it for a multichannel analyzer because it has enough memory and all the peripherals of interest, including USB.