Dual-mode / DUALCTRL on 28pin device, possible?

[gordonthree]

Device is a AVR128DA28 ... Platformio IDE

I've been trying to get this going for a bit now, no luck. It works fine as Host only or Client only but won't do both on two different sets of pins.

The chips never automatically ACK their addresses to the Host, and don't see any clients when I do a scan on the Host pins. The interrupts never trigger either.

Here's my setup()

int I2C_CLIENT_ADDR = 0x34;

HardwareSerial &ser = Serial1;  // setup ser to point to serial1 uart

#if defined(TWI_MORS_BOTH)
  HardwareI2C &i2c_host = TWI1;
  HardwareI2C &i2c_client = TWI0;
#endif

void setup() {
  pinMode(PIN_PF0, INPUT_PULLUP); // pins for client address configuration
  pinMode(PIN_PF1, INPUT_PULLUP);

  bool addr0 = digitalRead(PIN_PF0); // see what our hardwired address is
  bool addr1 = digitalRead(PIN_PF1);

  #ifndef PM_CLIENT_ADDRESS
  I2C_CLIENT_ADDR |= (addr0 | (addr1<<1)); // compute address
  #else
  I2C_CLIENT_ADDR = PM_CLIENT_ADDRESS;     // use what was sent during compile
  #endif

  #if defined(TWI_MORS_BOTH) // 32pins and bigger, don't have any yet
    i2c_host.begin(); // i2c_Host is TWI1, using default pins PF2, PF3
    i2c_host.setClock(100000);  // bus speed 100khz

    // i2c_Client is TWI0, accept default pins, should be PA2, PA3
    i2c_client.begin(I2C_CLIENT_ADDR, false); // Client on twi0
  #elif defined(TWI_MANDS_SINGLE)  // 28pin device
    // Setup TWI0 for dual mode ... TWI_MANDS_SINGLE
    Wire.enableDualMode(false); // enable fmp+ is false
    Wire.begin(); // setup host PA2 and PA3
    Wire.begin(I2C_CLIENT_ADDR, false); // setup client with address, ignore broadcast PC2 and PC3
    Wire.setClock(100000);
  #else // client only
    Wire.begin(I2C_CLIENT_ADDR); // PA2 and PA3
  #endif

  #ifdef TWI_MANDS_SINGLE 
    #pragma message "TWI_MANDS_SINGLE defined!"
  #endif

  delay(2000);

  ser.begin(115200); 

  sprintf(buff, "\n\nHello, world!\nClient address: 0x%X\nDUALCTRL: 0x%X\n", I2C_CLIENT_ADDR, TWI0_DUALCTRL);
  ser.print(buff);


  ser.flush();

  scanI2C();  // scan bus?!

  Wire.onRequest(requestEvent); // register requestEvent interrupt handler
  Wire.onReceive(receiveEvent); // register receiveEvent interrupt handler
}

[ObviousInRetrospect]

https://ww1.microchip.com/downloads/aemDocuments/documents/MCU08/ProductDocuments/DataSheets/AVR128DA28-32-48-64-Data-Sheet-40002183C.pdf page 154 says dual mode defaults to master on A2/A3 slave on C2/C3 so its not the pinout

Did you check the simple stuff like pull-ups on the bus to which C2/C3 is connected?

is the onReceive/onRequest handler being called (blink an LED or something)

[ObviousInRetrospect]

and since you are using platform IO, there is a configuration option under the boards menu for Arduino to enable dual mode. You'll need to turn the equivalent on in PIO.

[gordonthree]

page 154 says dual mode defaults to master on A2/A3 slave on C2/C3 so its not the pinout

datasheet revision C ... hah I was using the ds linked from Digikey, which points to rev A.

Moving my busses around, the local host bus is now finding local clients! However, the client bus on PC2/PC3, is not responding to the upstream host. A step in the right direction at least.

here is a configuration option under the boards menu for Arduino to enable dual mode. You'll need to turn the equivalent on in PIO

I couldn't find any fuses that needed to be set, so I'm working with the assumption that menu is setting a build flag. I am setting flags TWI_MANDS_SINGLE and TWI0_DUALCTRL ... near as I can tell those are the flags the libraries are looking for. Where are those menu options defined? boards.txt maybe?

[ObviousInRetrospect]

yeah boards.txt. I think TWI_MANDS_SINGLE is right. There is a second bit I don't understand being set as well.

having just wasted days debugging what turned out to be an Arduino 2.0 issue I would suggest you take the 5 minutes and load this into 1.8.13 set the board option and verify you get the same behavior to separate platformio from other.

also can you confirm pull-ups on the client bus? and/or another device on that bus that responds correctly?

[gordonthree]

also can you confirm pull-ups on the client bus? and/or another device on that bus that responds correctly?

confirmed, 10k pullups on the upstream host bus. I have confirmed that the upstream host bus is working properly, it detects its local RTC and eeprom

yeah boards.txt. I think TWI_MANDS_SINGLE is right. There is a second bit I don't understand being set as well.

from reading boards.txt for my chip, here's what I've come up with in build flags

-DMANDS_SINGLE                ; From boards.txt twi0 supports master AND slave mode
-DCORE_ATTACH_ALL          ; From boards.txt attach interrupts to all pins (default)
-Wl,-u,vfprintf -lprintf_flt           ; from boards.txt full printf support

I will copy and paste my setup into an Arduino sketch and see what happens. I too am a bit concerned about this, but it looks like Platformio is pulling 1.4.10, the latest release.

[gordonthree]

5 minutes and load this into 1.8.13 set the board option and verify you get the same behavior to separate platformio from other.

well s**t ... the stripped down code works in Arduino 1.8.19

I so dislike the Arduino IDE ... but if that's what it takes to get this project to the finish line, I guess I move forward.

[ObviousInRetrospect]

I totally agree with you on the Arduino IDE 1.x sucking as an IDE

You might try 2.0 (WITH THE SPECIFIED CLI VERSION INSTALLED - SEE SpenceKonde/megaTinyCore#760) yes I posted that over in megaTinyCore but DxCore has the same issue. The 2.0 IDE sucks a lot less than the 1.x ide.

And/or stay with platform IO but build in Arduino.

[gordonthree]

And/or stay with platform IO but build in Arduino.

The code doesn't compile clean as-is between the IDEs, probably due to my terrible discipline in coding style, platformio seems more forgiving, despite Arduino letting you get away with more things.

[gordonthree]

One last ditch effort, hopefully someone, maybe @SpenceKonde or @MX682X can explain what changes these two lines make to the build?

avrda.menu.wiremode.mands1.build.wire.mode=MANDS_SINGLE 
^^^ i thought this one was a build flag?
avrda.menu.wiremode.mands1.build.wireabr=.wA
^^^ no idea what wireabr or .wA means

[MX682X]

1. There are basically 4 modes - a combination of the following MANDS/MORS - SINGLE/DUAL.
   Master AND Slave / Master OR Slave
   SINGLE - you can use either TWI0 or TWI1 for the pins, basically backwards compatibility to old libraries if you have to use pins of TWI1
   DUAL - creates Wire1 object, but limits the pin choice to the corresponding modules

So, basically, MANDS_SINGLE allows to call begin() "twice", for master and slave (it also adds a buffer and counters for slave transmissions in the Wire class). You can also use swapModule() to use either TWI0 or TWI1 and swap() will choose the pins accordingly to the module.
Hope this helped.

2. wireabr seems to be only an abrivation for some internals. there is .wO .wA .wO2 .wA2 (the 4 choices) I have no idea what Spence is using this for.

[MX682X]

#if defined(TWI_MORS_BOTH)
  HardwareI2C &i2c_host = TWI1;
  HardwareI2C &i2c_client = TWI0;
#endif


i2c_host.begin(); // i2c_Host is TWI1, using default pins PF2, PF3
i2c_host.setClock(100000);  // bus speed 100khz

// i2c_Client is TWI0, accept default pins, should be PA2, PA3
i2c_client.begin(I2C_CLIENT_ADDR, false); // Client on twi0

I'm pretty sure this will not work. TWI0 and TWI1 are pointers to the hardware modules, but you want to access them as Class structures. You have to use Wire0 and Wire1 instead.

Oh, and I would recomend to set the callback functions before begin(). I don't know how good the optimization is, but I know that if the compiler knows the function in advance, it just skips the check for a NULL pointer because it knows, that this pointer is set before the interrupt routine fires.

[gordonthree]

Hopefully I'll have some 32 pin chips shortly, and I can forget about trying to get Dual-mode working at least temporarily. I will try your suggestion for setting the pointers correctly.

Thanks for the insight about the boards.txt contents... I found mands_single pop up a bunch of places. Was hoping that was the difference I was missing between platformio and Arduino, but alas not yet.

[MX682X]

I forgot to tell you one more thing - Don't use the HardwareI2C class. it is not functional right now (@SpenceKonde I think this needs the same changes as with the HardwareSerial class (aka renaming class names or make a #define)) Please use TwoWire for now instead.

(It was done this way because HardwareI2C unneccarily bloated the code with it's virtual functions)

[SpenceKonde]

Wait, what's wrong with hardwareI2C? I thought I got rid of that issue before the Dx was even released, because someone was bitching about the bloat in I2C and how on an attiny412, he couldn't use I2C at all because it was so bloated.

Serial may well be busted in master here though. I need to port the changes from here over to mTC and from mTC to here. (here has autobaud support, while mTC got @MX682X's magic wand waved over it

[MX682X]

You are right in terms of that you got rid of HardwareI2C, but as you can see above, there are people trying to use it. I think it might lead to some problems so it might be useful to create a #define HardwareI2C TwoWire for compatibility. Or something similar.

[SpenceKonde]

Thanks, good thinking

[MX682X]

On a side note: Why do you want to use the Dual mode?

I think there might be a misunderstanding, judging by your settings. Dual mode means only that the slave part of the TWI is connected to pins other then master. This only makes sense, in my opinion, on the DB and DD series that have MVIO or when there are two different I2C clocks.
If you want to use the DA in a multi-master configuration, aka two DAs for example, you can connect both with the same pins (e.g. PA2/PA3) and have a bidirectional master communication (when using Master and Slave).

[ObviousInRetrospect]

I've used dual mode successfully on the avr64db32. Pretty similar use case. I generally try to avoid multimaster i2c as having more potential for things to go wrong. If nothing else the timing is certainly less deterministic.

re your battery pack, have you looked @ MAX17303G+? Might do much of what you need (or potentially be useful as an adc + cutoff that actually does the right thing). I'm starting to play around with it. With an appropriate footprint its not terrible to hand solder (lengthen the pads by ~1mm in the out direction and add a big via under it to solder the pad).

https://datasheets.maximintegrated.com/en/ds/MAX17300-MAX17313.pdf

[gordonthree]

Maxim, TI and Linear all had some interesting candidates, that's essentially what I'm building is a fuel gauge and protection board, with everything broken out instead of internally integrated into a tiny chip. Soldering a 3mm 14 pin leadless package doesn't sound like my idea of something to hand solder. How does one check for solder bridges with everything hidden under the chip package? I think the smallest I've bothered to hand solder is the 10mSOP package, half the pitch of standard SO I believe?

[ObviousInRetrospect]

So that was my initial reaction as well to DFNs and again to 0.4mm pitch DFNs. But having done a few I've found DFNs are far less annoying than QFNs and go down consistently. The trick is to modify the footprint and use extra flux. If you make the pads about 1mm longer you can easily draw any bridges away from the chip (and use wick if needed). With either a bent tip or a knife tip you can also easily reflow an entire side at once which tends to snap it into perfect alignment. Worst case if you totally botch it if you have a $50 hot air rework station (858D or similar) hitting it with hot air and tapping with tweezers will usually cause it to snap perfectly into place.

When hand soldered the solder bonds to the edge more than the bottom. I haven't had problems with bridges under the chip since I am applying the solder to the side. (A few chips have pads only on the bottom rather than the bottom and edge. Those I have been less successful at hand soldering)

For inspection you need at least https://www.amazon.com/Illuminated-Microscope-Magnifiers-Magnifying-Magnification/dp/B08T9RV48H but a microscope is better.

I started trying to design something that sounds similar to what you are talking about. Where I reached the limits of my analog abilities was proper over discharge protection. I didn't know how to build a cutoff that when shut down would draw the ~100na that proper protectors draw to avoid draining the battery while coming back to life a few hundred mv higher. If you are totally allergic to DFN, https://www.digikey.com/en/products/detail/diodes-incorporated/AP9101CK6-ANTRG1/6187053 at least has a reasonable cutoff voltage (3.2v) instead of the usual 2.5v. Or if you have a design for a cutoff that works without further drain I'd be interested.

Maxim usually samples 4 for free. an oshpark board is about $2. I have one built, staring at the firmware now.

[SpenceKonde]

My tips for soldering qfn's and DFN's (shh, don't tell anyone):

• Stencil = not optional
• 158C Relife GLON solder paste = a true ally, You can rework parts by resting an iron on them and then manipulating with tweezers, and it's ROHS (they claim)
• Solder down with hot air.
• Rework with soldering iron using a tinned face only bevel tip or knife tip.
  IMHO, after 48 pins, where TQFP goes to the narrower spacing QFN is easier to solder because they self center better.

[ObviousInRetrospect]

For DFNs on modified footprints, Stencil = optional, just use an iron + leaded solder + flux. Faster to solder DFNs than 0.5mm pitch tssop.

[SpenceKonde]

It would be really great to have an example of dual mode where the chip acted as a slave to another chip, and a master to some random sensor. Cause, Like, I don't know off hand how to do it...

[MX682X]

well, the problem is, that platformio does not generate the .lst and .map files. only elf and hex. I found gordon's da28-mands-test repositry and tried to figure out where the problem was but was not able to find anything suspicious. But it is possible to generate the .lst file from the .elf, so that was my plan.

Of course, the .lst files would be preferable, if you figure out how to make them in platformio. Couldn't find a solution through internet searches

[gordonthree]

@MX682X here are the files:

The Arduino zip has seemingly everything including the .lst and .map files
In Platformio I was only able to find the .elf and .hex files, not sure where it puts the other stuff at.

arduinofiles.zip
platformfiles.zip

[MX682X]

0000088a <TwoWire::write(unsigned char)>:
     88a:	fc 01       	movw	r30, r24
     88c:	86 85       	ldd	r24, Z+14	; 0x0e
     88e:	df 01       	movw	r26, r30
     890:	84 ff       	sbrs	r24, 4
...

(basically equals to this)

#if defined(TWI_MANDS)                   // Add following if host and client are split
    if (vars._bools._toggleStreamFn == 0x01) {
      ...
    } else
  #endif

I can tell that the arduino code has MANDS defined, but the platformio, missing this part of assembly, has it not defined

I recomend you to add the following to your platformio twi source files:

#if defined (TWI_MANDS)
 #warning TWI_MANDS defined
#else 
#warning TWI_MANDS not defined
#endif

(or similar)
This way you can tell at compile time if it is defined.
Or: use the uncomented defines that you can find in twi.h to make sure it is always defined

[gordonthree]

Interesting! On platformio I've been using the build flag -DTWI_MANDS_SINGLE ... will try changing the define in platformio.ini to and testing for TWI_MANDS in my code

Thanks for the analysis!

[gordonthree]

I can tell that the arduino code has MANDS defined, but the platformio, missing this part of assembly, has it not defined

That was it, missing one simple define! Someday I'll have to learn that analysis you preformed, to find those clues myself. Thank you so much for diving into my code to come up with the answers 😁

[SpenceKonde]

In any event, I would very very much like to have a known working reliable demo of dual mode in the examples.

[MX682X]

/**
 *@brief      getBytesRead provides a facility for the slave to check how many bytes were
 *              successfully read by the master.
 *
 *            Useful for implementing a "register model" like most I2C hardware does.
 *            Calling this will reset the counter, since it is an unusual use case for          <------
 *              that to not be the next thing you do.                                           <------
 *
 *@return     uint8_t
 *@retval     Number of bytes read by a master from this device acting as a slave since
 *              the last time this was called.
 */

uint8_t TwoWire::getBytesRead() {
  uint8_t* txTail;
  #if defined(TWI_MANDS)                         // Add following if host and client are split
      txTail   = &(vars._bytesReadWrittenS);
  #else
    #if defined(TWI_MERGE_BUFFERS)               // Same Buffers for tx/rx
      txTail   = &(vars._bytesReadWritten);
    #else                                        // Separate tx/rx Buffers
      txTail   = &(vars._bytesWritten);
    #endif
  #endif
  // txTail variable (what ever applies on the mode) is reset on every slave AddrRead  <-------
  return (*txTail);
}

The problems that are created when multiple people work on the same code.......

Basically, in your requestHandler(), ObviousInRetrospect, the bytes_read variable is always 0.

I have two fixes in mind:

1. the txTail and Head is currently also reset at a STOP condition. By keeping the txTail until a new ADDR condition, the user could check in the loop the growing number. It would be useless in the onReceive/onRequest functions though.
2. an extra uint8_t counter variable that is incremented by the txTail at the ADDR condition and getBytesRead() returns counter + txTail with a reset of the counter variable.

Also, if the code is not working with SLEEP_MODE_STANDBY, best to open a new Discussion thread or Issue and explain in Detail where you get corrupted data.

[gordonthree]

reading 0xFF aka -1 usually means the buffer is empty. And since onReceive / onRequest only fires after a transmission is finished, that means there can't be any buffer underflows except there is more data transmitted then the buffer can hold

if 0xFF is reserved, what is the procedure to send data with that value?

[MX682X]

actually read() return int, aka int16_t. So, when you read() and the buffer is empty, it returns 0xFFFF, but is casted to 0xFF when you read it to a byte. When you have a 0xFF in the buffer, it returns 0x00FF. It usually doesn't matter since the amount of read Bytes is known, it is passed in the onReceive function as an argument and as return value in requestFrom

Edit: code Example:

uint8_t i;
uint8_t arr[ ];
int byte = Wire.read();
if (byte != -1) arr[i++] = (uint8_t) byte;

[gordonthree]

Oh well that probably explains why I'm seeing some weirdness trying to read individual uint8_t 😅 using .read()

[ObviousInRetrospect]

@MX682X I opened issue #322 covering the sleep mode issue.

[gordonthree]

In the file platformio.ini, add -DTWI_MANDS to build_flags, shout out to MX682X for this answer!

build_flags = -DTWI_MANDS            ; From MX682X

[SpenceKonde]

this reminds me....

We really need a guide on how to use DxCore and megaTinyCore with platformIO.

But it requires someone with deep knowledge of both the cores and platformIO. I have knowledge of cores, but 0 knowledge of platform IO.