GCBASIC / Discussion / Programmers and Chip Files Problems: V98 RC06 18f4620 USART baudrate and PLLEN bit

kent_twt4 - 2017-09-24

So after testing 18f46k20 and 18f46k22 INTOSC settings and verifying with HSerPrint at 9600 baud, I decided to test the older 18f4620 device.

The 18f4620 HSerPrint demo program expects the baud to be 9600, but will only work at 4800 and is affected the same way across the whole range of frequencies of 1-32Mhz.

Looking at INITSYS the OSCCON IRCF and PLLEN bits are NOT being set correctly. The 18f4620 has the ability to set the INTOSC to 32 and 16Mhz with 4xPLL and INTOSC of 8 and 4Mhz respectively. The #config OSC = INTIO67 needs to be set for PLL speeds.

When chip Mhz = 16 and #config OSC=INTIO67, the IRCF bits are being set to 112 and no PLLEN bit being set. Would expect IRCF bits to be 96 plus the PLLEN being set.

When chip Mhz = 32 and #config OSC=INTIO67, the IRCF bits are 96, and the PLLEN bit is being set. So would expect IRCF bits to be 112, and PLLEN bit set.

When chip Mhz = 8 the IRCF bits = 96. Would expect IRCF bits to be 112. And so on down the line of chipmhz, same problem.

So could be that 18f logic needs to be reconciled between the newer and older 18f's whereby the newer 18f's IRCF bits = 112 means and 16Mhz intosc, and the older 18f's where IRCF bits = 112 and 8Mhz intosc.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2017-09-24
  
  Ok I try and sort on Monday.
  
  Did this work in previous releases?
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

kent_twt4 - 2017-09-24

Yes 18f4620 IRCF bits worked correctly in previous releases:
v95.008 - Good
v97.01 - Good
v98 RC05 - Good

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2017-09-24
  
  Ok. That is good news. Check here on Monday.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

kent_twt4 - 2017-09-24

Another look, and trouble with 18f4620 started at the replacement RC06 system.h, so that is good.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2017-09-25

See https://sourceforge.net/p/gcbasic/code/629/tree/GCBASIC/trunk/include/lowlevel/system.h?format=raw

Please retest all the chips. This is getting more robust each time.

INITSYS now handles two true tables for frequency... between 64 (with PLL when required) and 0.125x. Tested on 18f2425 (type1 max frq of 8mhz) and 18f26k22 (type2 max frq of 16mhz).

I have tested with scope not RS232 - all looks ok.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2017-09-25
  
  And, I have updated some the .dat files. I will issuenew dat files with the final release. Changes as follows. You may have to edit your RC6 files when you testing.
  
  I will explain the list for the first record only. This is an extract of the changes from the chip database.
  
  -PIC18F25K80,16,1024,3648,24,8,64,16,No,28,0,0,0 'was max int osc of 8mhz
  +PIC18F25K80,16,1024,3648,24,8,64,64,No,28,0,0,0 'now max int osc of 64mhz - 16mhz * 4 PLL
  
  -PIC18F2620,32,1024,3968,25,10,40,8,No,28,0,0,0
  +PIC18F2620,32,1024,3968,25,10,40,32,No,28,0,0,0
  
  -PIC18F26K80,32,1024,3648,24,8,64,16,No,28,0,0,0
  +PIC18F26K80,32,1024,3648,24,8,64,64,No,28,0,0,0
  
  -PIC18F4525,24,1024,3968,36,13,40,8,PSP,40,0,0,0
  +PIC18F4525,24,1024,3968,36,13,40,32,PSP,40,0,0,0
  
  -PIC18F45K80,16,1024,3648,35,11,64,16,No,44,0,0,0
  +PIC18F45K80,16,1024,3648,35,11,64,64,No,44,0,0,0
  
  -PIC18F4620,32,1024,3968,36,13,40,8,PSP,40,0,0,0
  +PIC18F4620,32,1024,3968,36,13,40,32,PSP,40,0,0,0
  
  -PIC18F46K80,32,1024,3648,35,11,64,16,No,44,0,0,0
  +PIC18F46K80,32,1024,3648,35,11,64,64,No,44,0,0,0
  
  -PIC18F6525,24,,3840,,12,40,,No,64,0,0,0
  +PIC18F6525,24,,3840,,12,40,32,No,64,0,0,0
  
  -PIC18F65K80,16,1024,3648,54,11,64,16,No,64,0,0,0
  +PIC18F65K80,16,1024,3648,54,11,64,64,No,64,0,0,0
  
  -PIC18F66K80,32,1024,3648,54,11,64,16,No,64,0,0,0
  +PIC18F66K80,32,1024,3648,54,11,64,64,No,64,0,0,0
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Anobium - 2017-09-25

Tested 18F45K80, 18F4550, 16f1939, 18f26k20, 18f25k50 = OK

Last edit: Anobium 2017-09-25

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2017-09-25
  
  So, I think the following files should all have the Max Internal OSC updated - they all have PLL and therefore the Max Internal OSC should be set appropiately.
  
  I need some to review a sample before I make the change,
  
  ChipName
  
  PIC18f1230, PIC18f1330, PIC18f13k50, PIC18f14k50, PIC18f2221, PIC18f2321, PIC18f2410, PIC18f2420, PIC18f2423, PIC18f2480, PIC18f24j10, PIC18f24j11, PIC18f24j50, PIC18f24k50, PIC18f2510, PIC18f2515, PIC18f2520, PIC18f2523, PIC18f2525, PIC18f2580, PIC18f2585, PIC18f25j10, PIC18f25j11, PIC18f25j50, PIC18f25k50, PIC18f2610, PIC18f2620, PIC18f2680, PIC18f2682, PIC18f2685, PIC18f26j11, PIC18f26j13, PIC18f26j50, PIC18f26j53, PIC18f27j13, PIC18f27j53. PIC18f4221, PIC18f4321, PIC18f4410, PIC18f4420, PIC18f4423, PIC18f4480, PIC18f44j10, PIC18f44j11, PIC18f44j50, PIC18f4510, PIC18f4515, PIC18f4520, PIC18f4523, PIC18f4525, PIC18f4580, PIC18f4585, PIC18f45j10, PIC18f45j11, PIC18f45j50, PIC18f45k50, PIC18f4610, PIC18f4620, PIC18f4680, PIC18f4682, PIC18f4685, PIC18f46j11, PIC18f46j13
  PIC18f46j50, PIC18f46j53, PIC18f47j13, PIC18f47j53, PIC18f6310, PIC18f6390, PIC18f6393, PIC18f63j11, PIC18f63j90, PIC18f6410, PIC18f6490, PIC18f6493, PIC18f64j11, PIC18f64j90, PIC18f6525, PIC18f6527, PIC18f6585, PIC18f65j10, PIC18f65j11, PIC18f65j15, PIC18f65j50, PIC18f65j90, PIC18f65k90, PIC18f6621, PIC18f6622, PIC18f6627, PIC18f6628, PIC18f6680, PIC18f66j10, PIC18f66j11, PIC18f66j15, PIC18f66j16, PIC18f66j50, PIC18f66j55, PIC18f66j60, PIC18f66j65, PIC18f66j90, PIC18f66j93, PIC18f66k90, PIC18f6722, PIC18f6723, PIC18f67j10, PIC18f67j11, PIC18f67j50, PIC18f67j60, PIC18f67j90, PIC18f67j93, PIC18f67j94, PIC18f67k90, PIC18f8310, PIC18f8390, PIC18f8393, PIC18f83j11, PIC18f83j90, PIC18f8410, PIC18f8490, PIC18f8493, PIC18f84j11, PIC18f84j90, PIC18f8525, PIC18f8527, PIC18f8585, PIC18f85j10, PIC18f85j11, PIC18f85j15, PIC18f85j50, PIC18f85j90, PIC18f85k90, PIC18f8621, PIC18f8622, PIC18f8627, PIC18f8628, PIC18f8680, PIC18f86j10, PIC18f86j11, PIC18f86j15, PIC18f86j16, PIC18f86j50, PIC18f86j55, PIC18f86j60, PIC18f86j6, PIC18f86j72, PIC18f86j90, PIC18f86j93, PIC18f86k90, PIC18f8722, PIC18f8723, PIC18f87j10, PIC18f87j11, PIC18f87j50, PIC18f87j60, PIC18f87j72, PIC18f87j90, PIC18f87j93, PIC18f87j94, PIC18f87k90, PIC18f96j60, PIC18f96j65, PIC18f97j60, PIC18f97j94
  
  Last edit: Anobium 2017-09-25
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

kent_twt4 - 2017-09-25

These devices do not have an internal osc block in the traditional sense, only 31khz. PLL is only for OSC=HS.
18f24j10
18f25j10
18f44j10
18f45j10
18f65j10
18f65j15
18f66j10
18f66j15
18f85j10
18f85j15
18f86j10
18f86j15

Tested with HSerPrint, and the following were tested as AOK.

18f4620 ;manually added IntOsc=32 to dat I think?
18f46k20
18f46k22

I was going to test the 18f45j10, the only J family chip I have, when I found out about the intosc. I have zero PIC devices above 44 pins.

I may have a chance to test a few more smaller pinout devices and data sheets later.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Anobium - 2017-09-25
  
  18F*K22 and 18+FK20's are now INTOSC at 64 in the database.
  
  PIC18f2525 now at 32 in the database.
  PIC18f2620 now at 32 in the database.
  PIC18f4525 now at 32 in the database.
  PIC18f4620 now at 32 in the database.
  
  J10 and J15s no change.
  
  :-)
  
  Last edit: Anobium 2017-09-25
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Update as of 25th Sept 2017.

We have revised the system.h to support improved logic to cater for the 18f variants.
Kent has tested, I have tested. Looks ok.
The system.h SVN:CODE is the latest release.
However, you will need the dat files with today's date. Dat files have been refeshed to improve the support across the range.

So, if anyone want to validate the 18f configuration with respect INITSYS you will need the releases version of v0.98.00.

I think we are good to go. Kent has just confirmed the 18f14k50 (which was our last test failure) is working as expected.

Getting closer to the release

And, don't hijack the thread - please post other subjects elsewhere!

Last edit: Anobium 2017-09-25

Updated as of 26th Sept 2017. The story continues but is coming to an end.

INITSYS Failed on test. Revising the system.h to support improved logic to cater for the 18f variants failed on test. Chips were being set with the incorrect value and therefore the chip frequency was incorrect. There are 18f variants that do not compy with simple logic.

So, after much hair pulling I have change the header format of the .dat file to identify the OSCCON bit layout.

The .dat file now has with the OSCCON bit layout. Added IntOSCCONFormat as follows:

IntOSCCONFormat
Not present
	111 = 8 MHz (INTOSC drives clock directly)
	110 = 4 MHz
	101 = 2 MHz
	100 = 1 MHz(3)
	011 = 500 kHz
	010 = 250 kHz
	001 = 125 kHz
= 1
	111 = HF-INTOSC output frequency is used (16 MHz)
	110 = HF-INTOSC/2 output frequency is used (8 MHz, default)
	101 = HF-INTOSC/4 output frequency is used (4 MHz)
	100 = HF-INTOSC/8 output frequency is used (2 MHz)
	011 = HF-INTOSC/16 output frequency is used (1 MHz)
	010 = HF-INTOSC/32 output frequency is used (500 kHz)
	001 = HF-INTOSC/64 output frequency is used (250 kHz)

Using this method means we can config a DAT file per chip with NO assumptions on the OSCCON bit layout.

This does mean that there is a new set of .dat files required , These will be posted to SVN when we have completed testing.
This does mean an updated system.h to support ChipIntOSCCONFormat. This will be posted to SVN when we have completed testing.
Chips with IntOSCCONFormat. I have updated the chip database with the chips shown below. This list may not be 100% correct but anyone got a few hours to wade through the datasheet.. Let us know if you need the database updating.
From a support perspective this is a great approach. The generated ASM currently shows the value of ChipIntOSCCONFormat (if present) and the ASM shows the OSCCON setting. We will remove this from the ASM in the next release. This is for support.
Also, from a support perspective this is a great approach. If we miss a chip, in terms of having IntOSCCONFormat in the dat file, or, we have assigned a chip incorrectly the workaround is to update the dat file. Of course... letting us know so we can update the database!

Chips that been assigned with IntOSCCONFormat =1 @ 26092017

PIC18F13K22, PIC18F13K50, PIC18F14K22, PIC18F14K50, PIC18F23K20, 
PIC18F23K22, PIC18F24K20, PIC18F24K22, PIC18F24K40, PIC18F24K50, 
PIC18F25K20, PIC18F25K22, PIC18F25K80, PIC18F26K20, PIC18F26K22, 
PIC18F26K80, PIC18F43K20, PIC18F43K22, PIC18F44K20, PIC18F44K22, 
PIC18F45K20, PIC18F45K22, PIC18F45K50, PIC18F45K80, PIC18F46K20, 
PIC18F46K22, PIC18F46K80, PIC18F65K22, PIC18F65K80, PIC18F65K90, 
PIC18F66K22, PIC18F66K80, PIC18F66K90, PIC18F67K22, PIC18F67K90, 
PIC18F85K22, PIC18F85K90, PIC18F86K22, PIC18F86K90, PIC18F87K22, 
PIC18F87K90

This list may be incorrect, have errors etc. Let us know if we have to update.

Finally, testing reports to follow. Another day of testing ahead - hopefully, the night shift (Kent) has had good results.

Last edit: Anobium 2017-09-26

kent_twt4 - 2017-09-26

Retested HSerPrint test with Evans newer 9/25/17 system.h and manually adding the IntOSCCONFormat=1 to following RC6 chipdata files.

18f14k22
18f14k50
18f46k20
18f46k22

HSerPrint test.

16f1827 Pass (control)
18lf1220 Pass
18lf14k22 Pass
18f14k50 Pass
18f4620 Pass
18f4550 Pass
18f46k20 Pass
18f46k22 Pass

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Look very good. No issues so far with my testing.

The new support info in the ASM is shown below. We will delete the support information at the next release. But, in the meanwhile we need it.

;nop ChipIntOSCCONFormat
  nop 1
;NOP ' NoBit(SPLLEN) And NoBit(IRCF3) Or Bit(INTSRC)) and ifdef Bit(HFIOFS)
  nop
;[canskip] IRCF2, IRCF1, IRCF0, SPLLEN = b'1101'   ;'1101' with PLL for ChipMHz 32
  bsf OSCCON,IRCF2,ACCESS
  bsf OSCCON,IRCF1,ACCESS
  bcf OSCCON,IRCF0,ACCESS
  bsf OSCTUNE,PLLEN,ACCESS

This code segment is actaully interesting... (yawn)... it show the use of [canskip] - this is a new command with error handling. See the latest Help http://gcbasic.sourceforge.net/help/_setting_variables.html for an explanation.

Last edit: Anobium 2017-09-26

Summary test results from today's testing,

Class	Chip	Type	Frequencies	Results
1	18f26k22	IntOSCCONFormat=1 where ;110 = 8 MHz	64,32,16,8,4,2,1,0.25	Pass
2	18f25k42	18F and has NDIV3 bit	64,48,32,16,8,4,2,1,0.25	Pass
1	18f45k80	IntOSCCONFormat = 1 where ;110 = 8 MHz	64,32,16,8,4,2,1	Pass
3	18f4525	18F NoBit(SPLLEN) And NoBit(IRCF3)where ;111 = 8 MHz	32,16,8,4,2,1	Pass
3	18f4550	18F NoBit(SPLLEN) And NoBit(IRCF3)where ;001 = 125 kHz	Lots	Pass
3	18f4620	18F NoBit(SPLLEN) And NoBit(IRCF3)where ;111 = 8 MHz	Lots	Pass
1	18f46k20	IntOSCCONFormat=1 where ;1101 with PLL = 32 Mhz	Lots	Pass
1	18f46k22	IntOSCCONFormat=1 where ;1111	Lots	Pass

We tested a much wider range of 18f's - these are not shown above. All passed.

Then, I ran the automated tests across all the demos. Good job I did. Found the 10F320 and 10F322 use the same method as the type #1 18f. So, added IntOSCCONFormat to those chips in the chip database.

I also did a search of the 16f DAT files. I can find no cases where the type #1 method is used... Only time will tell if we need to add IntOSCCONFormat to any 16f dat file.

Note: Three people can edit the chip database to edit and revise to add the IntOSCCONFormat. Hugh, Bill and myself. And, when v0.98.00 is release and you see a posting that relates to the incorrect frequency the first place to look is the ASM:INITSYS - is the setup appropiate for that chip? if not, check the datasheet before editing anything. :-)

Building the release now.

V98 RC06 18f4620 USART baudrate and PLLEN bit

Forums

Help

V98 RC06 18f4620 USART baudrate and PLLEN bit document.SUBSCRIPTION_OPTIONS = { "thing": "topic", "subscribed": false, "url": "subscribe", "icon": { "css": "fa fa-envelope-o" } };

V98 RC06 18f4620 USART baudrate and PLLEN bit