Teensy3.0 + STM32407 Discovery: I2C issue?

[tboy32]

I have a Teensy 3.0 (didn't have a 3.2 handy) pins 18/19 connected to a STM32F4 Discovery board pins PB11/PB10 (I2C2 SDA/SCL). I'm using 2.2k pullup resistors on both signals. The STM32 is the master sending the I2C data. The clock is about 275kHz. The wires connecting the two boards are about 6 inches long.

This chunk of code running on a Teensy 3.0:

Code: [Select]

#include <Wire.h>

void setup() {
  // put your setup code here, to run once:

   //Wire.begin(8);
}

void loop() {
  // put your main code here, to run repeatedly:

}results in the first waveform (refer to attached image). Channel 1 (yellow) is SDA, ch#2 is SCL.

If I simply uncomment the Wire.begin() function as in:

Code: [Select]

#include <Wire.h>

void setup() {
  // put your setup code here, to run once:

   Wire.begin(8);
}

void loop() {
  // put your main code here, to run repeatedly:

}the result is the second waveform.

Not sure what's going on. Any ideas?

[tboy32]

I found a comment in the Teensy's WireKinetis.cpp code which reads:

Code: [Select]

// On Teensy 3.0 external pullup resistors *MUST* be used
// the PORT_PCR_PE bit is ignored when in I2C mode
// I2C will not work at all without pullup resistors
// It might seem like setting PORT_PCR_PE & PORT_PCR_PS
// would enable pullup resistors.  However, there seems
// to be a bug in chip while I2C is enabled, where setting
// those causes the port to be driven strongly high.
However I am already using external pullups. I found a Teensy 3.2 to use instead just to make sure it wasn't related to this 3.0 bug. Using the Teensy 3.2, however, had the exact same results. I guess the next step is to go thru the code and brute force commenting out individual lines & running it until I find the offending one.

[Svgeesus]

You don't have any code in your main loop which would read the I2C signals coming from the master.

The Wire library is certainly capable of working on Teensy 3.x as I2C slave. I suggest you first read these resources:

https://www.pjrc.com/teensy/td_libs_Wire.html
https://forum.pjrc.com/threads/24544-Is-it-possible-to-have-a-Teensy-3-I2C-slave-with-the-standard-release-library

Then try running the example I2C receiver code, which you can find in the Arduino environment from File > Examples > Wire > slave_receiver

Remember to adjust the I2C address in that example to whatever your current setup is using.

There is also an improved library for Teensy which is better than Wire in several ways. But what you want can be done with Wire.
https://github.com/nox771/i2c_t3

[tboy32]

Thanks for those resources, Svgeesus.

I actually used a different address on the Teensy (8 in this example) than the address the master is looking for (0x48) intentionally. I2C should support multiple devices and those that do not match the address sent by the master should theoretically ignore the remaining data and not modify the states of SCL or SDA. So therefore in this example when I uncomment the Wire.begin line I expect the bus waveforms to look exactly the same as when it is commented (or if there was no slave device connected at all) as the Teensy should be ignoring the request. However, the Teensy is doing something with the SCL line (as you can see in the second image) even when there is no code to do so (unless it's in the Wire library somewhere or something else is going on).

I'll give the alternate I2C library you suggested a shot and see what happens.

[tboy32]

Using the i2c_t3 library as suggested above. New code:

Code: [Select]

#include <i2c_t3.h>

void setup() {
  // put your setup code here, to run once:

   Wire.begin(I2C_SLAVE, 8, I2C_PINS_18_19, I2C_PULLUP_EXT, 400000);
}

void loop() {
  // put your main code here, to run repeatedly:

}
Results in expected waveform. The Teensy is looking for an address of 8 but ignores (does not touch the I2C signals) the data from the STM32 because it's looking for a device at address 0x48. This is better than the original Wire library which modified the SCL line even when it did not match an address.

However, changing the 8 address to 0x48 results in the attached waveform. Some of the SCL pulses only rise to about 1v instead of being pulled all the way to GND or left alone to be pulled up by the resistor.

Also included is an annotated picture of the setup. In the picture everything is being powered by USB but I've also tried powering them with their own supplies and leaving the 5v link disconnected between them, as well as powering the Teensy's 5v supply from the Discovery which was being powered from a floating power supply channel.

I've also tried pulling up the resistors to the Teensy's 3.3v pin instead of the STM32's VDD at 3v but I get the same result either way.

[tboy32]

Tried the same thing using a Moteino Mega, but it won't do anything at all, with either library, no matter the address. I've used a Moteino Mega before in master I2C mode and it worked well.

Tried using a STM32 Nucleo board but my J-link won't connect to the target STM32 and of course the Segger forums are currently experiencing a MySQL error so I can't view the solutions Google tells me other people have had.

Tried a Pro Mini with similar results.

Tried a Raspberry Pi 3 with the pigpio library. Wouldn't respond to the master. The pigpio library states it only works up to 100kHz clocks with no guarantee above that but I figured I'd try. I'm guessing the 275kHz clock is too fast for it. 

Was going to try a FEZ Panda II but it's seemingly no longer supported in software.

Tried a Sparkfun/Cypress FreeSoC2 board and FINALLY had success! After finally getting around to using it I'm really liking it - especially the selectable 3.3/5v I/O signals and ability to do actual proper debugging.

That was a fun Saturday. Finally my various collection of dev boards pays off! Thanks for everyone's input!

[Nominal Animal]

Consider asking the same question at the PJRC.com forum. The owner, Paul Stoffregen, is the designer (and PJRC.com the manufacturer) of all the Teensy boards, and I've found him quite helpful in situations like this.