Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C Not responding in proper manner - stop bit is probably absent. #418

Open
nyh-workshop opened this issue Jun 2, 2018 · 2 comments
Open

Comments

@nyh-workshop
Copy link

Hello Majenko:

Chipkit version: 2.0.3
Board: Custom with PIC32MZ2048EFH064

I have written a small NES mini controller (I2C) driver for the Arduino, and testing it on the same Chipkit-based board. However, the Chipkit one does not respond at all.

So using a logic analyzer and probing the I2C lines on a normal one and the Chipkit's one revealed that there are some irregularities:

1.) Here, the part simply sends the address of the NES controller, and then writing 0xF0 and 0x55. And another one with the address, then writing 0xFB and 0x00. Note that the stop part is different at the Chipkit one:
image
And this is the functioning one:
first two bytes nes mini controller

The code fragment in reference to the I2C waveforms:

// Init the controller first!
Wire.begin();
// Non-encrypted setting message:
Wire.beginTransmission(address);
Wire.write(0xF0);
Wire.write(0x55);
Wire.endTransmission();
Wire.beginTransmission(address);
Wire.write(0xFB);
Wire.write(0x00);
Wire.endTransmission();

I have to use my own I2C library for it to work as usual there.

2.) Same goes to this, after doing (1) the system sends one 0x00 to the controller, and the system reads back the returned value for 8 times. Unfortunately, on the Chipkit, it returns only 0xff:
Here is the Chipkit's one, where it pulls the SDA high after the first byte is read for a long period, and rest is 0xFF:
image
And the normal one:
image

Again, the code for this part is as follows:

// Send a read command:
Wire.beginTransmission(address);
Wire.write(0x00);
Wire.endTransmission();
Wire.requestFrom(address, 8);

// Dump it into the i2c buffer:
for (unsigned char i = 0; i < 8; i++) {
i2cBuffer[i] = Wire.read();
}

I can replicate the normal trace from the plain Arduino with the same Chipkit but without the "Wire" and the "DTWI" libraries - I used a general I2C driver based on this website: https://electrosome.com/i2c-pic-microcontroller-mplab-xc8/ and modified it to suit the PIC32 series.

Is there anything that prevents the stop bit from functioning? It did look like the stop bit didn't get there at each end of the transmission for the Chipkit Wire library one.

@nyh-workshop nyh-workshop changed the title I2C Not responding in proper manner - Chipkit version: 2.0.3 I2C Not responding in proper manner - stop bit is probably absent. Jun 2, 2018
@majenkotech
Copy link
Member

I was experiencing some similar symptoms with Wire.h last week (working fine with DTWI). I didn't dig into it at the time though, since it was low priority. I may dig again soon.

@nyh-workshop
Copy link
Author

Thanks Majenko for helping out. Alright to drop a message here once it's done, so that I can update the Chipkit core and use the Wire libraries? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants