In the last post I described one of the changes I did to this design and how I improved the relay control. I have been using
an old Explorer 18 dev board to rebuild the firmware for the train
control using the XC8 compiler instead of the old C18 compiler. The C18
is not available anymore and occasionally there is need for the higher optimization
than what the free mode provides. The Explorer 18 allows me to use a
plugin module with a PIC8F47J53 instead of the processor soldered to the
board. This is the processor that is use for the train control design.
This design requires PPS for moving features to specific pins. The
second SPI port and few other peripherals are only available through
PPS. Due
to traffic on the MiWi network, the MRF24J40MA module prefers it's own
SPI port. The second SPI port is used for the I/O expanders (MCP23S18) and the
EEPROM that contains the network and train control configuration. (The
18F47J53 has no local EEPROM and I dont like using PIC flash unless
there is no choice, not enough usable cycles.) I still had the plugin I built
for the Explorer 18 that had the MiWi module on it and an EEPROM.
After re-documenting the plugin correctly, I was able to read and write
to the EEPROM in a small debug section at the beginning of the program.
(I am using the Analog Discovery 2 to monitor the SPI bus. Glad I
bought that!) However when running the whole program, the EEPROM read
would eventually fail later on in the program. I could read basic info
at the beginning of the program, but once the MiWi network connected, it
would fail to read. The SPI bus showed the EEPROM CS going active, but no clock.
Debugging this became quite fun, since all the EEPROM reads went through
one function, but the breakpoints would eventually cause Windows to
disconnect the USB and thus I would loose control of the program. The
code where the MiWi network is accessing the EEPROM is buried in a
library, which made it all the more fun.
I had assumed that once PPS was selected, all other functions were
overridden. After two days of debugging, I came to the conclusion that
this was obviously not true.
Here is what is on RC1
RC1 standard I/O pin
CCP8 capture/compare I/O
T1OSI Timer1 osc input
UOE USB UOE output
RP12 PPS pin
The capture/compare feature was turned off, Timer1 was set to internal
instruction clock and UOE is a configuration bit option, so this cant be
altered by code. At various run points, none of this changed. Then I
found this little tidbit in the Timer 1 section
"When Timer1 is enabled, the RC1/CCP8/T1OSI/UOE/RP12 and
RC0/T1OSO/T1CKI/RP11 pins become inputs. This means the values of
TRISC<1:0> are ignored and the pins are read as ‘0’."
Well this can't be true, because this worked on the original design, so
something else is going on. Then I found this footnote:
"The Timer1 oscillator crystal driver is powered whenever T1OSCEN
(T1CON<3>) or T3OSCEN (T3CON<3>) = 1. The circuit is enabled by the
logical OR of these two bits. When disabled, the inverter and feedback
resistor are disabled to eliminate power drain. The TMR1ON and TMR3ON
bits do not have to be enabled to power up the crystal driver."
This is where cut and paste gets you and Microchip Tech Docs staff is
guilty as anyone is. The PIC18F47J53 actually has 8 timers, and Timer3
and Timer5 are identical. For some reason the MiWi library wanted
T1OSCEN set,which turned on the crystal driver. The note implies that
this only applies to T1OSCEN and T3OSCEN, when in reality it is the
logical OR of T1 or T3 or T5 OSCEN as shown in the Timer schematic in
the data sheet. And then somehow T5OSCEN also was set. Timer 3/5 section
additionally explains that this processor has the capability to switch
to the Timer1 OSC as a clock source and this mode can turn the crystal
driver on also. Fortunately this is not used that I can find, but I
have put in a forced write for this register.
When ensuring that all these bits are in the proper state, the result is a stable system and the Explorer 18 connecting to the MiWi network in
the train room. Still need to verify that all the data transfers are
working, but that is much simpler than finding this.
On to the next task
No comments:
Post a Comment