Re: [Flashforth-devel] FF 3.8 onto newer PIC18FxxK22 chips

[Mikael N. <mik...@pp...>]

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...