Odroid XU4 -> https://www.hardkernel.co...oid-xu4-special-price/
Running arch linux arm version armv7l Linux 4.14.111-1-ARCH
level converter -> https://www.sparkfun.com/products/12009
Accelerometer/magnetometer -> https://www.pololu.com/product/2738
and of course, some typical things like a single pic16F15325 along with pickit4 and my laptop running arch linux and mplab MPLAB X IDE v5.05.
Attached is a zip of my pic program, my odroids i2c program, and several pictures of my oscilloscope at various stages of working communication and failed communication.
Since I am fairly new to pic and I2C, I decided to use the Mplab code configurator to do the majority of the setup for me. With this, I have actually gotten decently far and can get communication from the odroid to the chip.
Problems: My issues seem to come down to two different problems. First problem is that my communication works a fair amount of the time but it also fails quite a bit as well. The second is that once my communication fails, my pic chip seems to get locked up in some kind of error state which requires a reprogram from the pickit to solve.
Problem #1 communication failures: my pic is normally running on its internal clock at 4MHz. When in this state, if I run the 'test' binary on the odroid and send an array of 2 characters to the pic, there's about a 50/50 chance that the pic will read both, and send back an ack which will register on the odroid's 'test' program as a successful system write. On the other hand, if this communication fails, the program on the odroid will say "connection refused". All subsequent attempts at writing to the chip will get a "No such device or address" error. Pictures from my oscilloscope corresponding to each of these messages should be attached to this post. I'm trying to keep my pic's clock at 4MHz or less for reasons relating to pulse width modulation, but I feel the issues I'm having with that system probably belong in another post. In any case, I tried two things which seemed to alleviate my communication failures. First, I boosted the clock on my chip as high as 32MHz. This seemed to ensure that my write would never fail. After that, I set the clock back to 4MHz and eliminated everything from my program but the loop and two i2c read calls in-between. curious enough, this too seemed to fix my communication issue. This leads me to believe that the problem is the amount of time the pic spends on the switch statement in my program along with the pwm function calls that occur as a result.
As a response to this conclusion, I assumed that part of the issue was that while the pic was still performing operations, perhaps the odroid was trying to perform the next write operation. With this in mind, I implemented my own version of clock stretching. After the two i2c reads are completed, I set the SSP1CON1bits.CKP register to 0 which should hold the signal line low. I then proceed into my switch statement and call once of the pwm functions based upon the first i2c read. Once the switch is done, I then set SSP1CON1bits.CKP high again signaling the master odroid that it can send more data. This unfortunately caused my communications to become even more unstable than before so I commented the SSP1CON1bits.CKP lines out and pursued other options.
Problem #2 Com Failures are permanent: Once a failure occurs, my chip can only be recovered by reprogramming it or cycling the chips power. I'm fairly certain this is just me not implementing the correct failure routines for i2c but after having looked through the libraries generated by the MCC, I'm afraid I'm still at a loss. In the end, the only idea I had was that I could close and reopen the i2c slave driver whenever I got an unexpected read value on the pic. This did manage to make my com failures no longer permanent but the success/failure rate seemed even more erratic than before so I also commented out that code.
Sorry for the long post. Thank you for all for any help you may give Smile: