This week I worked on SPI (Series Peripheral Interface) communication from the PIC18F97J60 to 25LC256 series EEPROM which comes with the PICDEM.NET2 development board. It was a completely new area for me and I was reading up a lot about the basics of SPI communication supported by the PIC. I was able to find numerous examples available from the microchip website giving instructions on the aspects of coding for SPI communication.
The biggest help for me in understanding and coding for SPI, was the c18 libraries instruction manual provided by microchip. The manual gave clear directions in applying the standard instruction set included in the spi.h library. By following this I was able to come up with a simple code for communicating with the device.
However at that point I faced another problem. At first I had not researched on the rules of communicating with the 25LC256. Sending commands to the EEPROM was not as simple as the PIC. Therefore I went back to the datasheets and looked up the reading and writing commands to the EEPROM. After a thorough examination of all relevant datasheets I came to realize that I first had to select the chip, send write enable command, the write command, address high and address low bits and then send the data to be written. At each of these commands there were certain conditions to be met such as selecting and deselecting the pin at the write moments. The same methods were applied to reading from the EEPROM device.
By following these directives I then modified my code and altered it to include separate functions. During these alterations I came to realize the ease of using Github as version control software since it manages the changes that are made to the file.
In order to test the program I included simple instruction to send the data byte that is read from the 25LC256 to the PC through a UART (Universal Asynchronous Receive Transmit) connection. When tested the program did not yield any results and I found out that my codes are not working as it should.
I sought the help of my superior and he walked me through the debugging process. The first thing that was checked for is the UART connection. To test this, a character was sent to the UART transmit pin before execution of other codes. The UART was working fine and so we moved on to the SPI commands. The trick to debugging was testing from the simplest instructions to the more complex ones, hence the one byte instructions such as read and write was tested first. This was checked by altering the read status register and checking for its output. After some samples it was concluded that these were being executed correctly.
Testing the 2 byte commands showed that they were not operating perfectly. After careful scrutiny of the SPI instruction codes it showed that there was nothing wrong there, and so we checked for the output by looping the read instruction to read the same address a given number of times. It showed that one of the reads was not being output, from this it can be concluded that in one of the read instructions the data byte was being lost somewhere, however we could not be sure at which point it was ie: in the start, middle or the end of the read loop. To find out where the problem was occurring the loop was modified to count the number of reads and give the output for each read including the count. This showed that the last read was being performed but the last byte was not being sent. From all this we came to the realization that the UART was being closed before the last byte was being sent and hence by correcting this simple mistake the program started working perfectly.
0 Comments