Resolved. The clock operates as expected. See later in thread for GLCD library adaption.
edited by Anobium
This could be a chip problem, or a problem with settings but I'm curious if anyone else experienced it. A few weeks ago in the course of solving the EEPROM issue with the K40 I noticed that the K40 wouldn't run at 64 MHz on the internal oscillator. Further testing showed 32 MHz worked just fine but 48 MHz didn't work, either. However, for my project I was using the crystal oscillator, not the internal oscillator. I originally used a 4.194304 MHz crystal and the 4xPLL for a clock speed of 16.777216 MHz. This works fine. I needed a speed boost given that I'm using a 128x128 SSD1351 color display. Substituting a 10 MHz crystal for the 4.194304 MHz works fine also. That gives me a 40 MHz clock with the 4xPLL. However, a 16 MHz crystal doesn't work. It works fine without the 4xPLL but that's only a 16 MHz clock. A 14.318 MHz crystal didn't work, either, with the 4xPLL. The 4xPLL is speced to have an input frequency range of 4 MHz to 16 MHz, so it should work.
Given that the same problem exists whether I'm using the internal oscillator or the crystal oscillator, it looks like it's an issue with the 4xPLL. It just won't run with an input frequency over about 10 MHz. Now could this be caused by settings, or just an issue with this revision (A002) of the chip? I'm running the chip at 5V, so low voltage isn't the isssue.
On another note, the 18F2420, which is specified only to a maximum clock frequency of 40 MHz, works just fine with a 16 MHz crystal and the 4xPLL. In fact, even a 20 MHz crystal, giving an 80 MHz clock speed, works.
Last edit: Anobium 2019-10-13
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Let me have a proper look tomorrow. I am sure that if this is not documented in the errata then it is likely to be a config and/or an initialization issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So, now lets look at the ext OSC using at 16mhz crystal. Seems to work here with a 16mhz crystal attached to OSC1 and OSC2. Tested with a scope.
#chip18F27K40, 64'64Mhz with 4xPLL
#configFEXTOSC=HS' External Oscillator mode Selection bits->HS (crystal oscillator) above 8 MHz and PFM set to high power
#configRSTOSC=EXTOSC_4PLL' Power-up default value for COSC bits->EXTOSC with 4x PLL, with EXTOSC operating per FEXTOSC bits
#configCSWEN=ON' Clock Switch Enable bit->Writing to NOSC and NDIV is allowed'This is not needed but I have inclded for clarity' NOSC EXTOSC with 4x PLL and NDIV 1OSCCON1=0x20' CSWHOLD may proceed and SOSCPWR Low powerOSCCON3=0x00' MFOEN disabled and LFOEN disabled and ADOEN disabled and SOSCEN disabled and EXTOEN disabled and HFOEN disabled andOSCEN=0x00' HFFRQ 4_MHzOSCFRQ=0x02' TUN 0OSCTUNE=0x00; Wait for PLL to stabilizewaitwhile(PLLR=0)dirporta.0outdoporta.0=!porta.0wait10msloop
Last edit: Anobium 2019-10-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
None of that works at all for me unless I have CSWEN = OFF. When I have it off, it works fine with the 10 MHz crystal but not at all with the 16 MHz one. I honestly think this is an undocumented hardware issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Can you confirm you tried the code above? Unchanged with nothing attached to the microcontroller.
What version of the compiler etc.? Post the top lines of your ASM file.
The GCB compilerdoes sets the CSWEN = ON, and, this is correct. . So, I am puzzled. My guess - when you use the code above it works. So, when you set CSWEN=OFF you lockout changes with respect to NOSC and NDIV, so, your NOSC and NDIV changes in the code are ignored.
Then, what is your config of you crystal? caps etc? distance etc.? I am sure Chris Roper will help in getting that sorted.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The simple test program works, even with a 16 MHz crystal. PortA.0 pulses at a frequency of 50 Hz like it should. This is telling me there's definitely no issue with the crystal layout. I'm using 20 pf caps and a 330 ohm series resistor. It works with or without the series resistor.
The problem is when I try your config with my project. At that point nothing works, or at least I'm not getting anything on the OLED display.
Compiler version is 0.98.06 2019-06-12 (Windows 32 bit) with the new EEPROM .h you sent me a few weeks ago.
Last edit: Joseph Realmuto 2019-10-11
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, there are interrupts running, and I'm still writing to the EEPROM. All this works fine with the 10 MHz crystal and 4xPLL. Also, everything works fine with the 16 MHz crystal without the 4xPLL.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am clarifying. Can you confirm that the chip and its crystal support (with nothing else attached) does not operate at 64 mhz using the code below?
The code should toggle the port every 10 ms.
Evan
#chip18F27K40, 64'64Mhz with 4xPLL
#configFEXTOSC=HS' External Oscillator mode Selection bits->HS (crystal oscillator) above 8 MHz and PFM set to high power
#configRSTOSC=EXTOSC_4PLL' Power-up default value for COSC bits->EXTOSC with 4x PLL, with EXTOSC operating per FEXTOSC bits
#configCSWEN=ON' Clock Switch Enable bit->Writing to NOSC and NDIV is allowed'This is not needed but I have inclded for clarity' NOSC EXTOSC with 4x PLL and NDIV 1OSCCON1=0x20' CSWHOLD may proceed and SOSCPWR Low powerOSCCON3=0x00' MFOEN disabled and LFOEN disabled and ADOEN disabled and SOSCEN disabled and EXTOEN disabled and HFOEN disabled andOSCEN=0x00' HFFRQ 4_MHzOSCFRQ=0x02' TUN 0OSCTUNE=0x00; Wait for PLL to stabilizewaitwhile(PLLR=0)dirporta.0outdoporta.0=!porta.0wait10msloop
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That code with the chip and nothing but the crystal attached is working fine. The problem seems to be when the display attached. If I can sort it out with the simple test program I posted below (which just writes stuff to the display), all should be well.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to run a test program which just sends stuff to the display, without any interrupts or use of the EEPROM. It doesn't work with the 16 MHz crystal and 4xPLL but works fine if I swap in a 10 MHz crystal. This is starting to look like some sort of weird interaction between the display and the chip. Here's the test program:
I just made an interesting discovery. If I use the above program exactly as written it doesn't work. I tried changing CSWEN to ON. Still didn't work. However, if I change #chip PIC18F27K40,64 to #chip PIC18F27K40,32 then it works. I also tried #chip PIC18F27K40,48 but that doesn't work, either.
Here's another interesting thing. Any delay loops should in theory run at half the speed since the program is assuming a clock speed of 32 MHz, when in reality the clock is 64 MHz. However, they don't. They run at normal speed.
Same thing with my project. I tried #config FEXTOSC=HS, RSTOSC=EXTOSC_4PLL, BOREN=OFF, CSWEN = ON, WDTE = OFF and #chip PIC18F27K40,32. It works perfectly at 64 MHz.
Apparently there's some issue going on with either the compiler or the chipdata file.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
My code. What I just wrote above is wrong anyway. What happens for some reason when I use #chip PIC18F27K40,32 the compiler ends up having the chip running on the 32 MHz internal oscillator, not the external crystal oscillator, despite the configuration telling it to use the crystal oscillator. That explains why the delay loops work as expected.
The bottom line is I don't think I can make my project work at 64 MHz. I'll just have to accept that 40 MHz is all I can get. I attached the SSD1351 library. Maybe you can find something that I'm missing.
Wait for a few days. We are updating the compiler specifically to resolve the K40 memory issues. It may help. We are adding a cache to ensure the TABLAT and NVRAM bits are pointing at the correct part of PROGMEM and EEMEM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Resolved. The clock operates as expected. See later in thread for GLCD library adaption.
edited by Anobium
This could be a chip problem, or a problem with settings but I'm curious if anyone else experienced it. A few weeks ago in the course of solving the EEPROM issue with the K40 I noticed that the K40 wouldn't run at 64 MHz on the internal oscillator. Further testing showed 32 MHz worked just fine but 48 MHz didn't work, either. However, for my project I was using the crystal oscillator, not the internal oscillator. I originally used a 4.194304 MHz crystal and the 4xPLL for a clock speed of 16.777216 MHz. This works fine. I needed a speed boost given that I'm using a 128x128 SSD1351 color display. Substituting a 10 MHz crystal for the 4.194304 MHz works fine also. That gives me a 40 MHz clock with the 4xPLL. However, a 16 MHz crystal doesn't work. It works fine without the 4xPLL but that's only a 16 MHz clock. A 14.318 MHz crystal didn't work, either, with the 4xPLL. The 4xPLL is speced to have an input frequency range of 4 MHz to 16 MHz, so it should work.
Given that the same problem exists whether I'm using the internal oscillator or the crystal oscillator, it looks like it's an issue with the 4xPLL. It just won't run with an input frequency over about 10 MHz. Now could this be caused by settings, or just an issue with this revision (A002) of the chip? I'm running the chip at 5V, so low voltage isn't the isssue.
On another note, the 18F2420, which is specified only to a maximum clock frequency of 40 MHz, works just fine with a 16 MHz crystal and the 4xPLL. In fact, even a 20 MHz crystal, giving an 80 MHz clock speed, works.
Last edit: Anobium 2019-10-13
Have you tried more than one k40?
Yes. Same problem with all three I tried.
Let me have a proper look tomorrow. I am sure that if this is not documented in the errata then it is likely to be a config and/or an initialization issue.
Definitely not in the errata. I already checked.
I'm pretty sure I've ran a k40 at 64Mhz but now t with an xtal. To confirm what is the symtom, does it just run slow or hang?
I tried so many different settings. Sometimes it hangs, other times it just runs slow.
IntOsc can be 64, 48, 32, 24, 16, 8, 4, 2, 1, 0.5, 0.25, 0.125
These frequencies are all ok using the program below. . Tested with a scope.
So, now lets look at the ext OSC using at 16mhz crystal. Seems to work here with a 16mhz crystal attached to OSC1 and OSC2. Tested with a scope.
Last edit: Anobium 2019-10-11
None of that works at all for me unless I have CSWEN = OFF. When I have it off, it works fine with the 10 MHz crystal but not at all with the 16 MHz one. I honestly think this is an undocumented hardware issue.
Can you confirm you tried the code above? Unchanged with nothing attached to the microcontroller.
What version of the compiler etc.? Post the top lines of your ASM file.
The GCB compilerdoes sets the CSWEN = ON, and, this is correct. . So, I am puzzled. My guess - when you use the code above it works. So, when you set CSWEN=OFF you lockout changes with respect to NOSC and NDIV, so, your NOSC and NDIV changes in the code are ignored.
Then, what is your config of you crystal? caps etc? distance etc.? I am sure Chris Roper will help in getting that sorted.
The simple test program works, even with a 16 MHz crystal. PortA.0 pulses at a frequency of 50 Hz like it should. This is telling me there's definitely no issue with the crystal layout. I'm using 20 pf caps and a 330 ohm series resistor. It works with or without the series resistor.
The problem is when I try your config with my project. At that point nothing works, or at least I'm not getting anything on the OLED display.
Compiler version is 0.98.06 2019-06-12 (Windows 32 bit) with the new EEPROM .h you sent me a few weeks ago.
Last edit: Joseph Realmuto 2019-10-11
OK. This tells us that the basic chip is good. Does it work at 64mhz?
And, do have any interrupts running? and, are you still writing to the EEPROM?
Yes, there are interrupts running, and I'm still writing to the EEPROM. All this works fine with the 10 MHz crystal and 4xPLL. Also, everything works fine with the 16 MHz crystal without the 4xPLL.
I am clarifying. Can you confirm that the chip and its crystal support (with nothing else attached) does not operate at 64 mhz using the code below?
The code should toggle the port every 10 ms.
Evan
That code with the chip and nothing but the crystal attached is working fine. The problem seems to be when the display attached. If I can sort it out with the simple test program I posted below (which just writes stuff to the display), all should be well.
I'm trying to run a test program which just sends stuff to the display, without any interrupts or use of the EEPROM. It doesn't work with the 16 MHz crystal and 4xPLL but works fine if I swap in a 10 MHz crystal. This is starting to look like some sort of weird interaction between the display and the chip. Here's the test program:
So, it's not the chip frequency setup. Good we have that sorted..
Your code is not correct. Remove CSWEN = OFF.
Remove DisplayDigits was is this doing? We should have method to make the code portable.
Add #option explicit
Then, I would need all the code and the new library. I do not know is going on in those libraries.
I just made an interesting discovery. If I use the above program exactly as written it doesn't work. I tried changing CSWEN to ON. Still didn't work. However, if I change #chip PIC18F27K40,64 to #chip PIC18F27K40,32 then it works. I also tried #chip PIC18F27K40,48 but that doesn't work, either.
Here's another interesting thing. Any delay loops should in theory run at half the speed since the program is assuming a clock speed of 32 MHz, when in reality the clock is 64 MHz. However, they don't. They run at normal speed.
Same thing with my project. I tried #config FEXTOSC=HS, RSTOSC=EXTOSC_4PLL, BOREN=OFF, CSWEN = ON, WDTE = OFF and #chip PIC18F27K40,32. It works perfectly at 64 MHz.
Apparently there's some issue going on with either the compiler or the chipdata file.
I am very onfused. The 'as written' is that your code or my frequency test code?
My code. What I just wrote above is wrong anyway. What happens for some reason when I use #chip PIC18F27K40,32 the compiler ends up having the chip running on the 32 MHz internal oscillator, not the external crystal oscillator, despite the configuration telling it to use the crystal oscillator. That explains why the delay loops work as expected.
The bottom line is I don't think I can make my project work at 64 MHz. I'll just have to accept that 40 MHz is all I can get. I attached the SSD1351 library. Maybe you can find something that I'm missing.
I would remove
SSP1SSPPS = 0x0017 'RC7 > SS1I will remove everything after the first circle to make this easier to test.
Finally for today.
Wait for a few days. We are updating the compiler specifically to resolve the K40 memory issues. It may help. We are adding a cache to ensure the TABLAT and NVRAM bits are pointing at the correct part of PROGMEM and EEMEM.
I need your glcd.h and the other .
Attached.