i2c slave problems still

Ed Arnold · Guest

I am still having problems with my Master-Slave setup. The Master is a F877 running at 16Mhz, and the Slave is a F873 running at 8Mhz. I can get the ex_slave code to read back chars, but only at SLOW speed. The modified code, posted by Kenny, I am using for this project works great except the Slave never receives any data bytes. By the way, this code doesn't use any of CCS #use i2c routines. It works in every way, reads and writes, but doesn't allow data to be sent to the slave. This code also doesn't like FAST speed, but oh well. How does the PIC know when it is receiving data vs address? Does it simply flag the D/A bit after the first incomming byte (address) after start?

Thanks again for any help

Ed Arnold 
___________________________
This message was ported from CCS's old forum
Original Post ID: 8614

Thomas Blake · Guest

Ed,

Load the Master SSPADD with a link rate value which will slow down the comms, then test. If it works at a slow speed you can at least be sure the code is not very broken

#define FOSC 8000000 // whatever your xtal freq is
#define SSPADD 0x0093
#define BITRATE 40000 // Lower this as necessary

*SSPADD = FOSC/BITRATE/4-1;

This only needs to be done once each main() but it doesn't hurt if you do it every iteration. 
___________________________
This message was ported from CCS's old forum
Original Post ID: 8620

Ed Arnold · Guest

Thanks to Thomas for his post about the MSSP errata. My problem would sometimes a recieved byte, but fall thru the switch states to the error trap. I still don't know why, but resetting the i2c port seems to fix this. Does anyone know how CCS sets up their i2c Slave port? SSPM0:SSPM3 i2c Slave mode w/ START / STOP bit interrupts or i2c Slave mode, 7 bit? By looking at the heading of ex_slave, it looks like they use i2c Slave mode w/ START / STOP interrupts. Is there any advantage to using this mode? Should I add code to detect a STOP condition? Now that this code works, I need to allow the slave chip to take over the bus and the inform the original Master when it is finished. I know now, this is no small task, but I would welcome any help.

Thanks again

Ed Arnold
___________________________
This message was ported from CCS's old forum
Original Post ID: 8639

Emilio · Guest

:=I am still having problems with my Master-Slave setup. The Master is a F877 running at 16Mhz, and the Slave is a F873 running at 8Mhz. I can get the ex_slave code to read back chars, but only at SLOW speed. The modified code, posted by Kenny, I am using for this project works great except the Slave never receives any data bytes. By the way, this code doesn't use any of CCS #use i2c routines. It works in every way, reads and writes, but doesn't allow data to be sent to the slave. This code also doesn't like FAST speed, but oh well. How does the PIC know when it is receiving data vs address? Does it simply flag the D/A bit after the first incomming byte (address) after start?
:=
:=Thanks again for any help
:=
:=Ed Arnold 

Hello,

I have got the same problem. It would help me if you could show me this part of the code which is different from Kenny's.

Thanks

Emilio

___________________________
This message was ported from CCS's old forum
Original Post ID: 8681

Thomas Blake · Guest

Congratulations! I empirically discovered, when I originally implemented i2c slave in asm, that I had to mask the start bit (bit 3 of SSPSTAT) or the byte would fall through to state 5. (So I used a mask value of 0x25 rather than 0x2D.) Presumably it gets stuck in "1". This seems to be plain language for what the errata are saying. I suppose that by resetting the SSP you are forcing reset of the start bit each time. I haven't had time to try all the code examples given in this forum (i2c is a very popular subject, isn't it? Smile

) but the code at <a href="http://www.pic-c.com/forum/general/posts/8120.html" TARGET="_blank"> <a href="http://www.pic-c.com/forum/general/posts/8120.html" TARGET="_blank">http://www.pic-c.com/forum/general/posts/8120.html</a></a>
looks good, as it handles the start and stop explicitly by bit tests. If you leave the start test until the last comparison this should fool the SSP. Hopefully I will get time to work with all these over the weekend, as I am certainly not satsfied with what I have right now.
___________________________
This message was ported from CCS's old forum
Original Post ID: 8709