I am going to modify this series to include the PC software, since the PIC18F firmware and the PC software are intertwined. In the last post on this subject, I discussed some of the startup issues of getting the firmware working with the Microchip XC8 compiler, since the C18 compiler is no longer available and issues with the PIC18F47J53 itself.. Having worked through those issues, the "bringup time" on the real PCB was reduced. There were still several "coding issues" that had be resolved. I had put in quite a few compiler #ifdef directives. These blocked sections of code for the Explorer 18 Development board and the real PCB. Obviously I could not test the real PCB sections until the PCB was available. Mostly it was coding errors of PIC18F pins and registers.
It took a little more than a day to get the PIC18F47J53 working with the EEPROM, the MCP23S18 IO Expanders and the MRF24J40 module. So how do I test this.
Initial Testing
The first testing I do is timer testing. I have debug routines written for all the basic timers. In this processor those are, Timer1, Timer3 and Timer5. I have predefined periods of 1ms, 10ms and 25ms. Then I toggle a GPIO pin based on this and measure the output on a scope (Analog Discovery 2 in this case). This serves multiple purposes. First it verifies that all of the clock calculations that are defined are correct and that the timer periods are correct.
/*******************************************************************/
/********************** CLOCK DEFINITIONS **************************/
/* this is where the clock is set for calculations elsewhere */
/*******************************************************************/
#define CLOCK_FREQ 48000000
/*********************************************************************
* Overview: These macro returns clock frequency used in Hertz.
********************************************************************/
#define GetSystemClock() CLOCK_FREQ
#define SYS_CLK_FrequencySystemGet() CLOCK_FREQ
#define SYS_CLK_FrequencyPeripheralGet() (SYS_CLK_FrequencySystemGet()/4)
#define SYS_CLK_FrequencyInstructionGet() (SYS_CLK_FrequencySystemGet()/4)
#define FCY (SYS_CLK_FrequencyInstructionGet())
#define Fosc SYS_CLK_FrequencySystemGet()
Next I will toggle all the GPIO pins to make sure there are no PCB manufacturing errors and no soldering errors. Once this is done, I can move on to functionality testing. As you can see from the code segment below, I use #ifdef to block out the debug test routines that are located in the board initialization function. I have found this is much easier than commenting and uncommenting lines of code. The LED toggle is used a visual cue that something is happening and the code has not "crashed".
/*******************************************************************/
/********************** Debug Testing ONLY**************************/
#define EarlyDebugTesting
#ifdef EarlyDebugTesting
while (1)
{
TimerOutputTesting();
PICPortCycle();
SPIBus_WRITE();
SPIBus_READ();
GetBrdSerialNumber();
SaveBrdSerialNumber();
mLED_G_Toggle();
}
#endif
/*******************************************************************/
At this point in testing, the PC software communicating with the PIC18F firmware is how all remaining testing is done. I have created several "Testing Functions" in the PIC18F firmeare that are callable from the PC software. By changing what happens in these functions, allows me to exercise the entire PC software/PIC18F firmware USB HID interface and the device feature under test.
EEPROM Testing
First tests are can I write and read back the board serial number and EUI address. Once this was good I moved on to a much more complex operation. This involves storing the configuration data of the PCB. More on the features of this below. Once that worked and I could succesfully read back the configuration, the EEPROM testing was done. The only other thing I could have done is do write-read of all location using 0x55,0xAA and waling bits. Something you wold do in product manufacturing environment. But at this point, if the tests I was doing worked, this full access test would have worked also.
IO Expander (MCP23S18) Testing
Since the EEPROM was working, the SPI bus is working. That allows me to move on to more complex testing without having to worry about underlying issues. I chose to write to the GPIO output registers on each of the three devices. I write the two different bytes to each of the three devices (16 bit devices), then read them back. Then I did some simple checking that the output pins are moving. This was a little difficult since these are open drain outputs. But I turned on the weak pullups on the outputs to accomplish this testing.
Track Control Testing
As I explained in Part 3, there was some concern about not having pullups on these relay controls. But the MCP23S18 pullups worked just fine. Since the spring clamp connector was not installed yet, I used a DVOM to measure resistance between the track power feed and the track siding power connection. As I changed the siding power state in the PC software, the DVOM either shows a short or an open.
LED Control Testing
This was similar to the track control testing, except this is controlled by PIC18F GPIO pins that turn ON/OFF an N-Channel FET. As in the IO Expander testing, when the FET is off, the output is open drain. Since the spring clamp connector was already installed, I successively placed a 330 ohm resistor between the 5VDC point and the seven LED pins. Then the LED control pin either measure 5VDC or ground.
Relay Control Testing
This will be done in two parts. Once all the circuitry is installed, I will get a turnout and connect it to the PCB and then ground to the train transformer. Since the spring clamp connectors are not installed, I can use an appropriate size wire in the component holes to control the turnout on each of the 40 positions. Once this is done, I install the spring clamp connectors and run the test again. The first test is looking for cold solder joints, firmware issues and PCB manufacturing issues. The second test is looking only for soldering issues. The connectors are relatively expensive and hard to remove, so the first test hopefully eliminates any failures that would make the PCB unusable.
MiWi Testing
In the previous incarnation of the turnout and signal control board, I had spent a lot of time getting the MiWi to work. Also I had done a few consulting projects that used this MiWi Mesh Protocol. In the Explorer 18 Development board version, I used the latest non-library version that would compile under an XC8 compiler, did not want to deal with libraries. When I turned the development board on and the current train layout, the development board connected to that MiWi network and all was good. As described in this Blog Post, I use a Zena Device for the master station. The PC software connects to it over a USB HID interface and then sends/receives messages to/from the multiple turnout & signal control PCBs mounted under the layout. Most of the testing above is done using this PC interface and sending/receiving MiWi messages across the network. While this may not be a comprehensive test, bit error rate, messages dropped, etc, it is good enough for what I am trying to do.
In the next part I will describe the PC software in more detail and some of the issues that had to be resolved as well as others that may not be solved yet.
