Hello

I'm encountering weird problems with a PIC18F4525. I'm working over a design
I have working perfectly for over a year. The problem happens when I use the
SPI module.

The circuit uses 10 AD channels, PWM, capture, USART and now the SPI in
master mode . I did have a version that also used SPI without any problems
but that one used TMR2 for a 2 kHz clock. Now I'm using TMR2 for a 100 kHz
clock and so I'm driving SPI from clock/64. So here's the weird stuff that
happens when I enable SPI communication on the main loop:

- I can't touch the CCP1 pin, RC2. If grounded or simply touched upon with a
wire the processor will latch or reset. Configuring it as output doesn't
help.
- When communicating to the PC via USART the processor will reset or latch
in a minute or two.
- 20% of the times the processor is started from reset, it'll latch.
- the scope shows a 0,5 Vpp, 100 kHz square wave out of the CCP1 pin
regardless of being set as input or output. This mirrors the PWM pin next to
it.
- disabling pwm makes everything stop working.

With exception to the pwm mirror on ccp1, NONE of those things happen if I
simply comment-out the lines that load data into the SPI - all comes back to
normal. The difference is with SPI disabled a signal into CCP1 won't reset
the pic.

I've tried fresh pics, reducing the clock rate (seems to help a bit),
various software changes such as disabling interrupts when loading data into
the SPI, and I'm stumped. The datasheet errata is no help either. I'm using
C18 3.10 (the 3.11 release release notes show nothing of interest). Testing
is being done on a protoboard with other chips being a MAX232 and a serial
AD converter... Using ICD2 as debugger shows nothing, the processor simply
resets.

Now I also remember a problem we had last year that holding the CCP2 pin
high (then used as another capture instead of pwm) would latch the pic. The
solution at the time was to add an external timer to limit how long it would
remain high. I was hoping to get this working quickly to prototype our next
product with the existing firmware but if I can't solve this I'll probably
have to move to dsPICs which I'd have to eventually but would like to push
down the schedule of things... And praying the dsPICs won't show the same
weirdness...

So if anyone has some insight on stuff I could try or check you'll have my
grattitude. It's 3:30 am now...

Thanks in advance.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist