Stupid questions, some of which may not be applicable to your part:

Which pins on PortB?

Have you unplugged the programmer, as port B is where the programmer lives?

Have you disabled LVD?   Have you set reset to be an input instead of
~RESET~?

Are you sure the unit is not resetting?  I.E. read the reset register, turn
on a pin whenever it resets for a few cycles.   Are you sure the WDT isn't
enabled in the config words and you're getting WDT resets?   Same with the
brownout protection, etc.

Are you sure that *all* of the peripherals which use the port b pins you're
interested in are disabled?


On Wed, Dec 20, 2017 at 11:14 PM, andrew kelley <leetslacker@gmail.com>
wrote:

> Well, I have tried the following to no avail:
>
> swapped the chip out for another one (18f2550, other target that
> worked was a 18f4550)
> swapped the crystal out (20mhz, tried adding caps to ground like DS
> recommends, no change)
> swapped out bypass capacitors
> swapped out Vusb capacitor
>
> with no changes in behavior. I'd hate to have to retarget to a 18f4550
> but I don't see what is wrong. It is not a complex circuit.. basically
> just the USB connection (powered from USB), USB cap, decoupling caps,
> a few resistors (not connected to anything right now), and a couple
> NPN drivers (also not connected right now). The circuit is built on
> vector board and a .6" chip won't quite fit nearly as well, due to the
> other stuff already on the board (mostly LEDs and resistors, intent is
> to simulate a engine and capture the injector & coil pulse width to
> aid in testing the PCM while developing code instead of risking an
> engine).. I could put the PIC on a separate board because it only has
> 8 lines tied to the ECU.. Probably not a bad idea anyway to help
> isolate the PCM from the PIC.  Still it bothers me as to why the code
> runs fine on a 18f4550, but not a 18f2550. Not the target code mind
> you, but the simplest test code that reproduces the issue.
>
> <CODE>
> char degCtr;
> void main(void)
> {
>     char tmp;
>     TRISB=3D0;
>     degCtr=3D0;
>     while(1)
>     {
>                 tmp=3D255;
>                 while(tmp) tmp--;
>                 tmp=3D255;
>                 while(tmp) tmp--;
>                 degCtr++;
>                 LATB=3DdegCtr;
>     }
> }
> </CODE>
>
> On the 2550, that code glitches every ~7-8ms. I can change the values
> tmp is reloaded with and it does not change the glitch interval. Two
> different 2550's exhibit the same behavior (the third one I have would
> not program CONFIG bits properly, so I couldn't use it). However, 4550
> runs the same code, as expected, with PB7-PB0 cascading frequency
> outputs. The 2550 exhibits weird behavior, as though the degCtr is
> being reset or modified arbitrarily. There doesn't seem to be a
> pattern to the glitch other than the timing. WDT, BOR, STOVF, MCLR are
> disabled on both working and non working targets. I suppose it is
> possible that both 2550's are faulty but no real way to qualify that
> unless I order a few more.
>
> Yes I know the code is not optimally written.
>
> Appreciate all your collective patience with my debugging,
> Andrew
> --
> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
> View/change your membership options at
> http://mailman.mit.edu/mailman/listinfo/piclist
>



--=20
*Forrest Christian* *CEO**, PacketFlux Technologies, Inc.*
Tel: 406-449-3345 | Address: 3577 Countryside Road, Helena, MT 59602
forrestc@imach.com | http://www.packetflux.com
<http://www.linkedin.com/in/fwchristian>  <http://facebook.com/packetflux>
<http://twitter.com/@packetflux>
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.