Problem while programming attiny861a chip.

[rakehsaleem]

Hi @SpenceKonde, I am working on a project for which I used attiny861a chip but I am finding trouble in programming the chip. Previously, I used attiny85 for which I2C and power-down sleep mode works fine but then I required more pins for other functions. So I moved to attiny861a as it has more GPIOs and rest of the specs are the same with attiny85. However, I have no success in programming it as I tried to use your core and libraries and as u mentioned for I2C we can use wire library using your core but no SUCCESS so far. And then I tried using simple blink example too yet there is no output. Any pointers to troubleshoot would be great and also how or what library/core can be used to make I2C work with attiny861a chip. **For programming, I am using tiny AVR programmer from this below link..

Thank you!! -Rakeh

[binitshah]

Hi @rakehsaleem, were you able to figure out I2C on the attiny861? I'm using the same chip and facing the same troubles with the Wire lib.

[SpenceKonde]

Can anyone give me more information on what the issue with wire is???

[rakehsaleem]

Hello, so my problem initially was that I was unable to program the attiny861 chip to put into power-down-sleep mode but then I found out that my pin assignment was not right. The pin assignments as datasheets suggest—I was not getting it to work but after looking at the describe pin assignment, I made it to work and interrupts were working fine. Then, I have to work on the I2C part and I have to configure an RTC (ds1342) and a digital potentiometer (Max5479), but it's not working neither the RTC alarms are setup nor the potentiometer wipers are setting up with my programmed value. Previously, it was working with same lines of code as changing the chip has nothing to do with slave address, except the procedure of calling.

With attiny85—working

  TinyWireM.begin();
  TinyWireM.beginTransmission(MAX5479_ADD_U2);
  TinyWireM.send(C_BYTEWA);
  TinyWireM.send(0xff);
  int  someByte = TinyWireM.endTransmission();
  TinyWireM.begin();
  TinyWireM.beginTransmission(MAX5479_ADD_U2);
  TinyWireM.send(C_BYTEWB);
  TinyWireM.send(0x96);
  int  someByte1 = TinyWireM.endTransmission();

With attiny861(a)—Not working until now

  // MAX5479 digiPOT configuration for Strain
  Wire.begin();
  Wire.beginTransmission(MAX5479_ADD_U2);
  Wire.write(C_BYTEWA);
  Wire.write(0xff);                   // (0x80)send (0xff=full, 0x80=half, 0x40=one-fourth, 0x20=one-eighth) resistance value
  int Byte1 = Wire.endTransmission();
  Wire.begin();
  Wire.beginTransmission(MAX5479_ADD_U2);
  Wire.write(C_BYTEWB);
  Wire.write(0x80);                   //(26) send (0xff=full, 0x80=half, 0x40=one-fourth, 0x20=one-eighth) resistance value
  int Byte2 = Wire.endTransmission();

Keep in mind the slave address, register address and the next data commands are same.

Also, I have tried the clock to be 1Mhz and 8Mhz but for both, they are not working. The hardware connections had pull-up resistors as well as RTC is tested with coin-cell battery as well. Any advice would be appreciated because I have already assembled 10 pieces with this new 861(a) chip.

[SpenceKonde]

Does it work if you use Wire.h instead of TinyWireM on the tiny85?

[rakehsaleem]

No, tiny85 chip works with TinyWireM library only, therefore I also tested TinyWireM lib with 861 just to make sure. But right now, my configuration is Wire.h library with 86(a) chip!! Thanks for quick response.

[SpenceKonde]

So the Tiny85 works with TinyWireM, but does not work with Wire.h? That would mean that I should be looking in the USI portion of Wire.h for general problems - and not looking at anything specific to TinyWireM. TinyWireM IIRC only worked on a few parts, so the fact that it's not working on the 861 isn't a surprise.

[SpenceKonde]

The one in my repo, or one from somewhere else? Link me to it if from elsewhere.

[rakehsaleem]

I have not used—In fact, didn't look into your TinyWireM library. Instead, I was using the library from this website of Arduino. https://playground.arduino.cc/Code/USIi2c/. I have used the I2C master library from here and was using this one for so long until now when I changed the chip.

[SpenceKonde]

What are you getting back from the calls to Wire.endTransaction()? Also check if you're getting a 1 or 0 back from the Wire.write() calls - they return error codes, so that should help narrow things down...

[SpenceKonde]

Dear god..... these timings are all fucked up!

[SpenceKonde]

Actually.... maybe not.... but they are doing multiple things that they aren't supposed to for sure....

Note: You must use resistors on USI parts - you know that right? Using the builtin pullups is never enough, but on the USI parts it's not even possible as I understand...

[SpenceKonde]

That may be the worst peripheral in the history of the AVR architecture.....

[rakehsaleem]

Actually.... maybe not.... but they are doing multiple things that they aren't supposed to for sure....

Note: You must use resistors on USI parts - you know that right? Using the builtin pullups is never enough, but on the USI parts, it's not even possible as I understand...

Yes, I have used the pull-up resistors(4.7k and 10k, ohm) and not relying on builtin-pull ups actually. But still, there is no life on the pins. I have tried to troubleshoot with the oscilloscope and see if I get some signals on the SDA/SCL lines but yet no response onto them as well.

What are you getting back from the calls to Wire.endTransaction()? Also check if you're getting a 1 or 0 back from the Wire.write() calls - they return error codes, so that should help narrow things down...

I assume you mean Wire.endTransmission right? Actually, I have not seen the callback output for either the endTransaction or Wire.write() since it requires serial monitor and for some reason, I am getting access to serial but anyways, ill try again in the morning and see if it helps.

Do you think if I2C is making problem is there any other way maybe UART? Would that work using your core and library? Thanks

[SpenceKonde]

Can you take the modified version of the library I just added to a spin? (I don't want it in a release until this is verified as at least not making anything worse). Also, the USI is a horrible peripheral

Take a look at the pinout chart - there's a builtin software serial implementation named Serial (it is half duplex, and has all the problems of software serial, except that it only uses the analog comparator interrupt, instead of a whole port worth of PCINTs.

[SpenceKonde]

Like any software serial implementation, it's not great, but it's good enough to get a few bytes out for debug.

[binitshah]

Hi thanks for the help. I gave the modified version a spin, but no luck. Trying to get I2C communication between the attiny861 and a Raspi. i2cdetect doesn't see anything either, but works fine with an atmega328p.

I'll try between the attiny861 and an uno tomorrow, in case there's something about the Raspi acting up.

[rakehsaleem]

Thanks, @SpenceKonde for your help and making the necessary mods, I'm out of my station so it's not possible to test at least until Monday or Tuesday, but I would see if that works with new library.

Hi thanks for the help. I gave the modified version a spin, but no luck. Trying to get I2C communication between the attiny861 and a Raspi. i2cdetect doesn't see anything either but works fine with an atmega328p.

Happens to me also before but I'll check again this week and hope the spin would get me somewhere close to my results.

[SpenceKonde]

OH! I just noticed another change that might have fixed things without all of this mess - the definition of the SCL and SDA pins was backwards, and was fixed since the 1.4.1 release...

[binitshah]

Hey @SpenceKonde, I have been using 1.4.1, but no luck. I ended up turning a C library that did work into an Arduino library. One thing I noticed was that the 861 defs seem to use portB, while the library I forked off of is using portA pins.

Unfortunately, I'm working with a Raspberry Pi and there's some clock stretching issue between USI and Raspi that leads to extremely faulty I2C transactions. I'm not familiar with the issue, so my best guess is that the Arduino core has too much overhead in the main loop to get the timing right. Anyhow, I'm sticking to C and AVR land.

[SpenceKonde]

Yeah, 1.4.1 does not have the fixes - they are only in the github version. I can't add them to a release until someone has tested them, as I am concerned that this could cause breakage elsewhere.