Go Down

Topic: UNO board I2C pullups? Can be enabled/disabled? (Read 3 times) previous topic - next topic

louarnold

#10
Feb 25, 2013, 07:25 pm Last Edit: Feb 25, 2013, 08:58 pm by louarnold Reason: 1

Quote
The problem is simply that sometimes the module's output frequency doesn't change.

That code will only set the modules output frequency to one value once per run only. Therefore if you run the code again it will not change. Only when you power it down will it change.

Quote
but sometimes things work.

That points to decoupling problems. Where are the output wires going to? Maybe this is causing interference that is being picked up. I would add extra decoupling capacitors to the supply.

Mike... Another almost identical program sets it to the lowest frequency. High=0x00 and Low=0x00. Even if you send the same code, Wire.endTransmission()should not return an error.
The output wire - the CLK signal - goes to the scope only. Its about an inch long. In fact all the wires (there is no CLK~ or OE wire) from the board go to the breadboard and they are also about an inch long. For this current situation, the supply is the UNO board itself, and the module has 4.7uf and 0.01uf caps from the supply to ground, on board. What size cap must be applied in addition and where? All components are surface-mount technology.

Grumpy_Mike

I would check that the pull ups are actually enabled as that could cause those sorts of problems as well.
I would use a large capacitor across the supply at the module end. Start with 47uF and work up to 1000uF.
The other thing that could cause this is the I2C clock geeing too fast but I don't see how that can be the case.
Can you examin the waveforms on a scope?

louarnold

#12
Feb 25, 2013, 10:54 pm Last Edit: Feb 25, 2013, 11:23 pm by louarnold Reason: 1

I would check that the pull ups are actually enabled as that could cause those sorts of problems as well.
I would use a large capacitor across the supply at the module end. Start with 47uF and work up to 1000uF.
The other thing that could cause this is the I2C clock geeing too fast but I don't see how that can be the case.
Can you examin the waveforms on a scope?
To Grumpy_Mike.
I refloated the solder bridges for the pull-ups. SDA and SCL look good on the scope: 0V-5V swings for both. I tried the I2C address scan. It recognized two addresses: 0x17 and 0x7E. Now 0x17=(0x2E>>1). This is the address of the module. I have no idea what 0x7E might mean.
The program reports no errors.
I tried 3 caps from +5V to ground at the module wires, but the scanner reports the same addresses.

Grumpy_Mike

Welli am running out of ideas. Any chance of posting a photo of your setup?

louarnold

#14
Feb 25, 2013, 11:47 pm Last Edit: Feb 26, 2013, 04:40 am by louarnold Reason: 1

Welli am running out of ideas. Any chance of posting a photo of your setup?

here are some photos:
1 of the set-up. I can't get closer and stay in focus.
1 of the wave forms while the scanner sketch is running.

Just a note: The scanner sketch miss-reports the device address. Normally the device address is shifted right one bit before passing it to the Wire.beginTransmission(address) method. The Wire lib then shifts it left with 1 for a read, or 0 for a write before sending it out.:
----------------see twi.c, line 144:
  // build sla+w, slave device address + w bit
  twi_slarw = TW_READ; //TW_READ=1
  twi_slarw |= address << 1; //twi_slarw=twi_slarw ! (address<<1)
------------------
The passing program keeps the unshifted address.
Ex: -------------
const byte i2cAddress =(0x2E >>1);      // Wire lib shifts back left for IO;
...
Wire.beginTransmission(i2cAddress);
------------------------------
However, the scanner sketch passes raw unshifted address. So for the reported 0x17, Wire believes it to be 0x2E. For 0x7E, its 0x2F. These are the proper read and write addresses for the module. Once the sketch is corrected the correct addresses are reported. See the attachment.

Go Up