I2C on ATtiny 841

[ahshah]

Hi! I'm wondering if anyone's been able to get software i2c master functionality working recently on the latest codeline? I'm having trouble with using the 841 to control a device (A5600), however the same code is functioning fine with the Attiny85 (think slow mode was enabled when I tested). I've tried all sorts of pull ups on the 841 CLK/SDA lines (0 (meaning directly wired), 2k, 4.7k and 10k) to no avail. wire.endTransmission() is always returning an error (2: received NACK on transmit of address.) I understand that error reporting is unreliable, but also I can't get any data off the device. I've also tried enabling slow mode. Nothing seems to work, and no matter the wiring, I'm always getting error code 2.

Parts: https://www.amazon.com/Magnetic-Encoder-Induction-Measurement-Precision/dp/B094F8H591
Wiring:

A5600 Library + Main sketch: https://github.com/RobTillaart/AS5600/blob/master/examples/AS5600_position/AS5600_position.ino

In my investigation I did find some interesting pieces that I think is a bug. Here is relevant sections and source code locations:

The modern CW pin mapping:

$ cat hardware/ATTinyCore/avr/variants/tinyx41_cw/pins_arduino.h | grep -B 1 -A 6 "#define SCL "
/* Hardware I2C slave */
#define SCL                      PIN_PA6
#define SCL_PORT                 (PORTA)
#define SCL_PIN                  (6)
#define SDA                      PIN_PA4
#define SDA_PORT                 (PORTA)
#define SDA_PIN                  (4)

Versus the legacy ccw pin mapping:

$ cat hardware/ATTinyCore/avr/variants/tinyx41_legacy/pins_arduino.h  | grep -B 1 -A 6 "#define SCL "
/* Hardware I2C slave */
#define SCL                      PIN_PA6
#define SCL_PORT                 (PORTA)
#define SCL_PIN                  (6)
#define SDA                      PIN_PA4
#define SDA_PORT                 (PORTA)
#define SDA_PIN                  (4)

This doesn't seem right, as they both can't be the same if the pin ordering is changed between clockwise and counter clockwise- or maybe I just don't know enough about how the pin indexing works :)

I'm also seeing the following warnings when compiling:

/Users/user0/Documents/Arduino/hardware/ATTinyCore/avr/libraries/Wire/src/Wire.cpp:630:0: warning: "I2C_TIMEOUT" redefined
   #define I2C_TIMEOUT 100

In file included from /Users/user0/Documents/Arduino/hardware/ATTinyCore/avr/libraries/Wire/src/SoftWire.h:23:0,
                 from /Users/user0/Documents/Arduino/hardware/ATTinyCore/avr/libraries/Wire/src/Wire.cpp:614:
/Users/user0/Documents/Arduino/hardware/ATTinyCore/avr/libraries/Wire/src/SoftI2CMaster.h:141:0: note: this is the location of the previous definition
 #define I2C_TIMEOUT 0

[hmeijdam]

Do I see series resistors in your schematic I2C lines instead of pullup resistors?

[ahshah]

Sorry! The schematic is wrong. On the breadboard, those resistors are not in series, but infact go to Vcc, and then theres junction connection that goes to AS5600. I will fix the schematic!

[ahshah]

Thanks for catching my omission- just posted the fixed schematic.

[SpenceKonde]

Okay, 1. Your schematic clearly shows that those resistors are not wired as pullup resistors, they're wired as series resistors. I2C requires pullup resistors and an absence of series resistors. This shows the key part of what you showed, and the right and wrong ways drawn in different colors (note the scribble marks as I tried 4 pens after being unable to locate the red mechanical colored pencil, leaving me with just green, yellow, blue, and yellow-orange. - the yellows don't show up well, and blue and green seemed too close to depict the correct and incorrect wiring schemes.

SCL_PIN and SDA_PIN are not arduino pin numbers. That's SCL and SDA - those resolve to a pin number by way of the PIN_Pxn definition. I'm being considerably more forceful as time goes on on my cores about pushing PIN_Pxn... (both because I'm more aware of what an abomination the arbitrary numbering convention is - and because Microchip's been making it more useful to do this through consistent pin compatibility). On this, my first core, it wasn't even working pre-2.0.0 - the PIN_Pxn defines were missing for most parts. Next came mTC and I was determined to prevent pinmap proliferation from reaching crisis levels and give a way to refer to the same pin across vastly different pincounts (On a modern AVR, if the previous parts that had a PERIPH (whatever peripheral) that the new family also has, any pin mappings available on previous parts for which it has the pins must also be available plus any new ones they add. I think that's how the sole ZCD on the DD's became known as ZCD3: the small pincount DD's didn't have the pins used by any of the ZCDs, they didn't want to add a muxer for it, and the pin czar wouldn't let them move the pin of ZCD0, the only way out was to make a new ZCD that worked on a pin the DDs have in all pincounts). Drastic change from the days of the classic tinyAVRs this core supports, where as far as I could tell, they chose the pinouts with a dartboard. I think in general Atmel was poor at keeping their designers on the leash - look what they did with xmega - classic off-leash-engineer syndrome

On Dx-series I go even further and don't put the numbers on the pinout charts, because code is so much easier to work with (esp. since I end up running a lot of other people's code, often on a different device (either for diagnostic comparison, or because I'd have to stand up and walk across the room and rifle to find the board he was using, and I didn't think it was device dependent)

[ahshah]

Hi thanks for the explanation- as I mentioned to Hans above, I botched the drawing of the schematic, on the bread board the pins are wired much the same as you have it (in green). I've updated the schematic, with the correct placement of the registers. To double check I'm going to try again with populating a fresh bread board with 4.7k pull resistors and I'll report back.

Glad to know that pins_arduino.h is correct for legacy and cw orientations! That reduces the amount of testing by atleast one dimension.

[ahshah]

I've retested this, and made sure the resistors are 4.7k and are pulling up. the and can confirm that this configuration is not working on the 841, but is working on the 85. Since I'm just moving the green and blue jumper wires to the appropriate spot between the two chips I'm fairly confident that theres something outside the wiring and usage off pullups thats preventing me from reading from the sensor.
Happy to provide more information, or to try other things.

[ahshah]

Okay folks, its a rainy day. So I broke out my oscilloscope. The last known commit when I2C master functionality works correctly on the Tiny841 platform is when SoftI2CMaster.h is at the following revision:

commit 3853428275d5a3ed89e5318eb96c7ca3cfff245d
Author: Stephan Martin <designer2k2@gmail.com>
Date:   Sat Dec 17 18:11:51 2022 +0100

One or more changes thereafter break functionality.

Further, maybe I misunderstood the exchange with Spence earlier, but I now believe that the pins in hardware/ATTinyCore/avr/variants/tinyx41_cw/pins_arduino.h as they currently stand are not correct (they do not correspond to the wiring diagram here: https://github.com/SpenceKonde/ATTinyCore/blob/v2.0.0-devThis-is-the-head-submit-PRs-against-this/avr/extras/ATtiny_x41.md). In my opinion, they should be presented as such:

#define SCL                      PIN_PA4
#define SCL_PORT                 (PORTA)
#define SCL_PIN                  (4)
#define SDA                      PIN_PA6
#define SDA_PORT                 (PORTA)
#define SDA_PIN                  (6)

The way I narrowed everything down is by writing a simple I2C peripheral device program on the Tiny85. I then used another '85 to control the peripheral device. This controlling code was placed on an Tiny841 as well. The 'scope probes were placed on the diagrammed SDA/SCL lines. Channel 1 is always orange, and corresponds to what should be the SCL line, Channel 2, in blue, is what should be the SDA line.

First lets look at the waveforms for the tiny85 controller:

Seems to look pretty nice- clock seems fairly steady.

Here's what things look like on the tiny841 master, currently:

Seems odd- the clock pin on channel 2, and the data pin is on channel one. Simply reversing the lines didn't get the peripheral device to respond. So I did some differential diffing and moved the codeline for SoftI2CMaster.h only to commit 3853428. Heres the output on the scope:

Seems to look much better- we have a steady clock, but again on channel 2, which is connected to what is diagrammed as SDA on ATTinyCore doc (see above link) Reversing the code in tinyx41_cw/pins_arduino.h I get the following wave form:

Seems much more in line with the Tiny85 waveform as seen in first diagram. The clock is on channel 1 (orange) and we are getting data now on channel 2 (blue). Finally, hooking it up in the logical way (as one would expect via the pinout diagram) to the Tiny85 peripheral device, and its been smooth sailing (for this small contrived case anyway).

Hope this helps to make things better, happy to share the code and my wiring testbed that i'm using to help sort this out. Don't think its super necessary since the scope output is way easier to comprehend at a glance, but if it helps I'm happy to post.

[hmeijdam]

Nice piece of research

[SpenceKonde]

Wow, I looked at that quoted section of code like a dozen times before I saw that they were backwards there.

That definitely makes sense. I don't recall what any of the changes to softI2C were aimed at though, will have to dig into that. Of course that requires I also find a programmer and make it work. I don;'t know where any of my classic AVR programmers are as i'm in the middle of a chain of multiple relocations.