Atmel and ASF are killing me, TWI/I2C question

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I posted a while ago about an issue I was having with a SAM4S and an APDS9130. The part would work with ANY source other than the SAM4S. After some searching, it turns out that the issue was caused by the down shift on SCL and data transition on SDA being too close to each other <20nS, and the APDS9130 part was (I'm assuming) seeing this as a repeat start condition. To correct the condition, we switched to an Atmel G55, which ~conveniently~ has an offset register to deal with that exact problem. 

 

I'm now revisiting the APDS9130 part in another application, using an ATTINY85. Guess what....SAME EXACT ISSUE. The down clock and data transitions happen near simultaneously, and the APDS9130 will not respond with an ACK when addressed. 

 

My questions to all reading are have you seen this before? Is there a fix for this that I'm not seeing? I can't be the only one to have noticed this. 

 

Thanks for reading. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Appreciate the reply. 

 

So If I can read between the lines, this is a known thing? 

 

Really tight for space in this application, and would like to keep to something hand solder-able. Not sure I can make the jump to either of those. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can't answer your question as was unaware of that issue until you opened my eyes on that.

 

QFN can be soldered by hand; the pins' flanks should be tall enough (drag soldering, or, push solder to pin) else there's hot air.

QFN soldering tips and tricks - Power House - Blogs - TI E2E Community

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Familiar with QFN, not confident my iron will do the pitch without a headache. 

 

Writing out a pure bit-bang now, I'll see if I can avoid the USI altogether.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Drag soldering is somewhat pitch insensitive (akin to wave soldering during PCBA manufacturing)

Tip does matter some for push soldering.

Hot air is do-able.

 

edit:

How to Solder QFN MLF chips Using Hot Air without Solder Paste and Stencils - YouTube (7m24s) though with a short segment early in the video on drag soldering a QFN

though Schmartboard|ez, the following shows push soldering :

Hand Soldering .5mm QFN Component With SchmartBoard|ez - YouTube (2m45s) via Schmartboard Video Archives

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Feb 1, 2020 - 05:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am intrigued.   A 20MHz Tiny85 surely can't do I2C in less than 50ns.

 

I will dig out a Tiny85 and see what the Logic Analyser shows.

I will even get out the oscilloscope if the timing looks suspicious.

 

APDS9130  supports 400kHz bus speed i.e. 2500ns clock period.   With 600ns setup time for RepeatedStart.

 

Please can you post your USI code.   A USI Master is never going to be speedy.

 

David.

Last Edited: Sat. Feb 1, 2020 - 01:29 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Code is pretty simple at this point for testing. Image pulled right from the scope. The clock/data transitions are happening right on top of each other, exactly like I saw with the SAM4S. 

 

If I pull out an Arduino I can talk to the APDS just fine. Transitions there are ~250nS apart.

 

    /* Set PB0/2/ as HIGH for I2C */
    /* PORTB = | - | - | PORTB5 | PORTB4 | PORTB3 | PORTB2 | PORTB1 | PORTB0 |  */
    PORTB = PORTB | 0b00000101;

    /* Set PB0/2/4 as output */
    /* DDRB = | - | - | DDB5 | DDPB4 | DDB3 | DDB2 | DDB1 | DDB0 |  */
    DDRB = DDRB | 0b00010101;

    

    _delay_ms(10);

    TinyWireM.begin();
    
    TinyWireM.beginTransmission(APDS9130);
    //TinyWireM.send(0x82);
    //TinyWireM.send(0xFF);
    TinyWireM.endTransmission();

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your SDA changes on the SCL falling edge.   i.e the same AVR cpu cycle.

It is legal for SDA to change when SCL is low.

Regular data is read on the SCL rising edge.

 

A Stop or Start is detected if SDA changes when SCL is high.

 

Since I2C falling edge is always driven,  it will be very fast.   Even if there is greater capacitance on the SCL line,   I would expect the lines to switch within 2ns of each other.

 

There is little point in using the USI as a Master.   The USI hardware requires you to clock SCL in software.

So you might just as well use Fleury's i2cmaster.S and bit-bang the Master.    i2cmaster.S changes SDA after SCL has gone low.

 

Running a USI Master or a bit-banged Master on a 16MHz Tiny4313 shows that SDA changes when SCL is low.    My Logic Analyser shows a minimum 83ns i.e. 2 samples @ 24MHz.   This implies at least one 62.5ns AVR cpu cycles.

 

That is why I asked about your USI software.    Your scope trace does not look like TinyWire.

Regular AVR310 USI Master changes SDA when SCL is low.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Surely, you can get a screenshot direct from the 'scope - rather than taking photos ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done hundreds of I2C apps with AVR Mega's and tiny's, never had an issue like this, perhaps a photo of your setup would show something.

Can you give more details of your project, what are the slave devices?

 

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP is using APDS9130

The APDS9130 datasheet seems to have reasonable timing spec.

 

The scope trace in #8 seems to show SDA changing on the same cpu clock cycle as the SCL falling edge.

88ns implies hefty bus capacitance or poor AVR output impedance.   e.g. 400pF * 200R = 80ns

 

I looked at TinyWireM code.   It uses the regular AVR310 USI Master code.

 

I will post some Logic Analyser traces.    If I prescale F_CPU to 4MHz and bus to 100kHz,   my 24MS Saleae will have plenty of samples.    And I don't have to connect an oscilloscope.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
The OP is using APDS9130

Have you tried a slower bus speed, I2C does not have to run at max speed, and depending on your bus characteristics may not be able to run at max speed.

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The APDS9130 data sheet specifies a data hold time past the negative edge of 60nS (tHD;DAT). If I don't have that, the part hangs the bus.

 

SAM4S, and ATTINY85 both do not meet that requirement. The G55 does not either, but has a register offset available to compensate. Arduino parts I've used do meet that requirement (Mega/Uno).

I'm not sure what to say about that, other than what it is. 

 

I've had some success bit-banging, this seems to be the route I will go. 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Surely, you can get a screenshot direct from the 'scope - rather than taking photos ... ?

 

Sorry, didn't have a thumb drive on me.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

david.prentice wrote:
The OP is using APDS9130

Have you tried a slower bus speed, I2C does not have to run at max speed, and depending on your bus characteristics may not be able to run at max speed.

Jim

 

 

Bus speed does not alter the data changing ~with~ the falling clock.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:

I've done hundreds of I2C apps with AVR Mega's and tiny's, never had an issue like this, perhaps a photo of your setup would show something.

Can you give more details of your project, what are the slave devices?

 

Jim

 

 

ATTINY85, with PB0 and PB2 tied to SDA/SCL respectively. Connected directly to an APDS9130 one cm away. As I stated before, if I remove the ATTINY85 and replace it with an Arduino, I have good comms. The only difference in waveform between the two is that the Arduino meets the tHD;DAT spec.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the T85 has a USI which given the HW your better off using bit-bang, while the UNO has TWI which is specific to I2C protocol.

As mentioned before, the fluery ASM bit bang would be how I would do it.

Good luck.

Jim

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looking into it now, thank you.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


 

I ran 100kHz bus with USI and bit-bang on an ATtiny4313 prescaled to F_CPU=4MHz.

The Saleae Logic Analyser has 24MS per second.   i.e 42ns per sample.   This means 6 samples per AVR clock which should capture the timing sequence.

There was a DS1307 and a AT24C32 Slave on the bus.   3k3 pullups to 5V

 

 

Here is an USI sequence showing a Repeated-Start, address, read data, Stop, Start, address

The first two SDA falling edges are exactly on 1st and 3rd falling clock edge.   The timing marker is on the 8th clock falling edge.   There is a 125ns gap. 

 

 

 

 

 

 

 

 

 

Here is a zoomed view of 1st edge:

 

 

 

 

 

 

 

And this is a similar sequence from Fleury bit-bang:

 

 

 

Fleury provides distinct 1000ns gap between SDA fall and SCL on 1st and 3rd clock

The Timing marker also shows 125ns.   Since the AVR has been prescaled to 4MHz,   any AVR activity will be in 250ns bites.

 

Not all USI write bytes change SDA exactly on the SCL edge.

 

You can't alter the USI behaviour.   You can insert NOPs or delays in the Fleury bit-bang.

 

For completeness.   This is what the Fleury TWI sequence looks likeL

David.

 

Last Edited: Mon. Feb 3, 2020 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That is amazing analysis. Thank you.

 

I know the data hold tolerance of the APDS part is part of the issue, but it's interesting that USI would be so inconsistent. 

 

I have a home brew bit-bang running now, looking into Fleury tonight.