Very Strange bug TWI send data ATTiny84

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

Hello community,

 

I want to use my Tiny84 (slave) to communicate via I2C with my raspberry (master). I downloaded a library namely https://github.com/rambo/TinyWir... to do this. I changed a few things that it works with avr gcc (encapsulation, classes removed).

 

The short version:

It works but not always. There is some very strange behaviour involved in this...

 

The only thing I do is sending a char (for example 'Z') from Attiny to raspberry 100 times via I2C (read on why I'm doing this 100 times). On the raspberry side I use i2c_smbus_read_byte() function found in linux/i2c-dev.h to read this char.

 

 

Ok great, my console prints

 

Z

Z

Z

-

Z

Z

 

and so on. Now the thing is I really do not understand why there is a '-' between some of the 'Z's. For example if I send the character 'E' to my raspberry it prints

 

E

E

"

E

E

 

Here comes the strange thing: These characters (- and ") have ALWAYS half of the ASCII Code of my original characters no matter which character I origininally wanted to send. And I could not find a kind of pattern in their occurance.

 

Here is the Code I use to send the characters:

 

void usiTwiTransmitByte(uint8_t data)
{

  uint8_t tmphead;

  // wait for free space in buffer
  while ( txCount == TWI_TX_BUFFER_SIZE) ;

  // store data in buffer
  txBuf[ txHead ] = data;
  txHead = ( txHead + 1 ) & TWI_TX_BUFFER_MASK;
  txCount++;

} // end usiTwiTransmitByte

In fact I do not have a single clue why it works most of the time and then the Tiny says 'Oh let's send half the ASCII code the user requested'. If more infomration is needed I can post it here, but I wanted to do the post as short as possible. The github link above provides all the code I am currently using.

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

I2C is not speed critical, but most beginning users try to run it at max speed, either 100k, or 400k bps.  

Try a slower speed, say 50k and see if that helps!

Speed is set on the master end.

 

Jim

 

edit: added where speed is set

Last Edited: Wed. Sep 27, 2017 - 02:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Blackavar wrote:
ALWAYS half of the ASCII Code of my original characters 

ie, shifted one bit to the right; or, in other words, the LSB has been lost.

 

So the question is, where did it get lost?

 

Options are:

  1. in the AVR (ie, it was not transmitted properly in the first place);
  2. on the wire (ie, some corruption occurred);
  3. in the RPi hardware (ie, it was received incorreclty);
  4. in the RPi software (ie, some bug in the processing).

 

You need to take a methodical approach to find where the problem occurs - this is the essnce of debugging.

 

http://www.avrfreaks.net/comment...

 

Do you have an oscilloscope, logic analyser, or suchlike to check what's going on on the wires?

 

EDIT

 

typo

 

EDIT 2

 

There is also the possibility that the I2C is fine, and the problem is just in your "console prints" ...

Last Edited: Wed. Sep 27, 2017 - 02:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the RPi i2c implememntation is also not 100% correct

it does not behave correctly regards to clock stretching so the problem copuld easily be with your Pi & outside of your controll

 

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

Ok thanks for the replies!

 

Tomorrow I will slow down the speed in the first step to see if it works.

 

If it does not work I will try to find out where the LSB got lost. I have a MSO so in theory should be no problem.

 

@awneil: I use the printf standard C printf function to print to console and I receive the byte from the AVR with the i2c_smbus_read_byte() function from linux/i2c-dev.h.

 

Edit: I will also consider clock stretching never heard of it I'm new to hardware programming. I will read the fundamentals of it. Thanks for all your feedback!

 

Well tomorrow (CEST) I will write an update.

Last Edited: Wed. Sep 27, 2017 - 04:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After comparing the SCL on an oscilloscope I have the strong feeling that I have a problem with this so called 'clock stretching'

 

 

 

This image shows SDC while I have received a 'Z'. So all is fine.

 

Now on the other side when I receive a '-' (half the ASCII code of the 'Z') it looks not so fine anymore. There is this mysterious spike right in front of the cursors.

Looks not fine anymore

 

So am I right that this problems comes from clock stretching and is in fact a hardware bug of the Broadcom chip?

 

Edit: I changed the I2C bus speed to 50k in the device tree (I also verified it with the osci) but it has no effect. What do you suggest? Is there a kind of workaround?

 

Last Edited: Fri. Sep 29, 2017 - 08:35 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Blackavar wrote:
a hardware bug of the Broadcom chip?

This is not a question for an Atmel forum!

 

Jim

 

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

ki0bk wrote:
This is not a question for an Atmel forum!

I guess the RPi forum would be the next place to ask?

 

Post a link there to this thread, for t heir background.

 

Also Post a link here so that anyone interested can follow the outcome...

 

 

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

Solved. For anyne interested: The RPi Broadcom chip has a confirmed hardware bug and does not support clock stretching which my Tiny was using.

 

The solution is not to use the RPi hardware and to implement a software I2C.

 

Anyway without the help of you I am certain that I would not have solved this by my own. Thank you.