Thread: [Flashforth-devel] FF 3.8 onto newer PIC18FxxK22 chips
Brought to you by:
oh2aun
From: craig b. <dab...@ya...> - 2013-09-16 17:51:56
|
Hi. I'm new at this email/online support thing, but played with Forth in the later 80-s and have been programming assembler into PIC16 chips for a couple of decades. PIC18-s, only occasionally (the PIC17 was brand new back then) but appreciate the architecture. I've gotten FF up and running nicely on 18F4550-s and an 18F4458 recently, but would like to use it in an 18F26K22 with the double UART. I've built a p18f26k22.cfg file with the config-bit settings and flash-write parms, extended the p18fxxxx.cfg file to cover the chip, tweaked the p18f-main.cfg and added a few small mods to the OSCCON and baudrate code in the ff_usb.asm to try and use the on-board intosc-pll combo to goose it up to 64Mhz operation. So far, I haven't gotten anything coherent out of the primary uart at any baudrate. My BitScope in logic mode shows me a quick series of blips (several per ms) for a few ms, a ms-long active bump, and then idle except for a blip each time the watchdog overflows. I didn't touch the watchdogging... Every change I've made to the config-bits or adding debug routines to the startup sequence has made it worse if not hung it completely. Has anyone else tried this stunt and/or have any suggestions about what I'm missing (besides "Don't fix a working program") ? Thanks and I hope this isn't a major intrusion. craig bair, binary behaviorist ...not a speck of serial... |
From: Mikael N. <mik...@pp...> - 2013-09-16 19:34:47
|
Craig, Hard to say what the problem is. I don't have that chip series myself. I would do the following. Configure a simple oscillator conf without clock switching. Configure the OSCCON so that it matches the assumed clock frequency. Disable the watchdog in the configbits. Debug it in the simulator to check that it nicely runs in RX1 waiting for input. After that try to get the UART working on the target. What exactly are your configuration bits, and the OSCCON value ? BR Mike On 09/16/2013 08:51 PM, craig bair wrote: > Hi. I'm new at this email/online support thing, but played with Forth in the later 80-s and have been programming assembler into PIC16 chips for a couple of decades. PIC18-s, only occasionally (the PIC17 was brand new back then) but appreciate the architecture. > > I've gotten FF up and running nicely on 18F4550-s and an 18F4458 recently, but would like to use it in an 18F26K22 with the double UART. I've built a p18f26k22.cfg file with the config-bit settings and flash-write parms, extended the p18fxxxx.cfg file to cover the chip, tweaked the p18f-main.cfg and added a few small mods to the OSCCON and baudrate code in the ff_usb.asm to try and use the on-board intosc-pll combo to goose it up to 64Mhz operation. > > So far, I haven't gotten anything coherent out of the primary uart at any baudrate. My BitScope in logic mode shows me a quick series of blips (several per ms) for a few ms, a ms-long active bump, and then idle except for a blip each time the watchdog overflows. I didn't touch the watchdogging... Every change I've made to the config-bits or adding debug routines to the startup sequence has made it worse if not hung it completely. > > Has anyone else tried this stunt and/or have any suggestions about what I'm missing (besides "Don't fix a working program") ? > > Thanks and I hope this isn't a major intrusion. > > craig bair, binary behaviorist > > ...not a speck of serial... |
From: Mikael N. <mik...@pp...> - 2013-09-16 21:22:16
|
Craig, please reply to the list. Others may have some input also. If the ms-timer interrupts are not firing and you have idle mode in use there will be watchdog resets occuring. That could explain some of your problems. How should the timers be configured to use the internal clock as source on these chips ? BR Mike On 09/16/2013 11:34 PM, craig bair wrote: > Mike, > > OSCCON wants to be 0xF0 and OSCTUNE wants PLLEN set (0x40)... OSCCON2 is fine on default. > I went a few rounds with the PLL before finding out that it only works with Primary Clock Selected. > > That setup was what drove me to tinker with the .ASM file. Well, that and the need to go into 16-bit BRG mode to get the UART into the right range. > > CONFIG BITS: > config FOSC = INTIO67 ;Internal oscillator block > ; config FOSC = ECMPIO6 ;EC oscillator (medium power, 500 kHz-16 MHz) > ; Note: PLL only operates with PRIMARY CLOCK > config PLLCFG = ON ;Oscillator multiplied by 4 > config PRICLKEN = ON ;Primary clock enabled > config FCMEN = OFF ;Fail-Safe Clock Monitor disabled > config IESO = OFF ;Oscillator Switchover mode disabled > config PWRTEN= OFF ;ON ;Power up timer enabled > config BOREN = OFF ;Brown-out Reset disabled in hardware and software > config BORV = 285 ;VBOR set to 2.85 V nominal > config WDTEN = ON ;WDT is always enabled. SWDTEN bit has no effect > config WDTPS = 256 ;Watchdog Timer Postscale > ; CCP2 MUX bit: > ; config CCP2MX = PORTB3 ;CCP2 input/output is multiplexed with RB3 > config CCP2MX = PORTC1 ;CCP2 input/output is multiplexed with RC1 > config PBADEN = OFF ;PORTB<5:0> pins are configured as digital I/O on Reset > ; P3A/CCP3 Mux bit: > ; config CCP3MX = PORTC6 ;P3A/CCP3 input/output is mulitplexed with RC6 > ; config CCP3MX = PORTB5 ;P3A/CCP3 input/output is multiplexed with RB5 > config HFOFST = OFF ;HFINTOSC output and ready status are delayed by the oscillator stable status > ; Timer3 Clock input mux bit: > ; config T3CMX = PORTB5 ;T3CKI is on RB5 > ; config T3CMX = PORTC0 ;T3CKI is on RC0 > ; ECCP2 B output mux bit: > ; config P2BMX = PORTC0 ;P2B is on RC0 > ; config P2BMX = PORTB5 ;P2B is on RB5 > config MCLRE = EXTMCLR ;MCLR pin enabled, RE3 input pin disabled > config STVREN = ON ;Stack full/underflow will cause Reset > config LVP = OFF ;Single-Supply ICSP disabled > config XINST = OFF ;Instruction set extension and Indexed Addressing mode disabled > config DEBUG = OFF ;Background Debug disabled > > > > The SIM is dicey for the PIC18FxxK22 chips and may not get fixed with the new MPLab-X takeover. I'm still running XP single-core machines, so I really can't afford the processor overhead of JAVA-based software. At least not until the economy picks up again. > > what I DID stumble across building up pieces and running test routines on the chip was that the ms-timer interrupts weren't firing. I've gone back into the docs for TMR3 and there are different bit-settings for timer osc inputs and the original takes it off the external pin. I'm switching it to System Clock (Fosc) and I'll see what that does. > > Thanks for the comments/suggestions, I'm pretty isolated and don't get to chat with programmers often. > > craig > > ...not a speck of serial... > |