AVR Freaks

I think I understand the general concept of how TWI works but the details are killing me. As you can notice I'm not experienced and therefore I'm struggling to understand the settings and what they do!

For instance, I know that SDAHOLD is a some setting that defines the amount of time that one line needs to hold a certain level before it can change to detect and confirm some specific action. But my struggle is that I don't know what for is this setting needed and if this setting is to automatically avoid the user to be worrying about timings.

For instance, to send a Star Condition I have this registers from the header file:

TWI_MCMD_REPSTART_gc = (0x01<<0),  /* Issue Repeated Start Condition */

So, I assume that to send a start condition to start sending a packet I would do:

TWI0_MCTRLB = TWI_MCMD_REPSTART_gc;

Then I know that the hardware needs to hold the SDA line for some time while SCL is low so that this condition is detected and confirmed as being a Start (or Repeated Start Condition) but I don't know if I need to manually write a delay function for this or if that SDAHOLD setting takes care of it automatically!

Ohhh ,man... I hate this...

I've been reading the same crap over and over again and now that I'm reading the description of this register MADDR I found myself thinking if I need anything I read before...

It says there that when this bit field (I would say byte field), a Start condition and an Slave address protocol is initiated.

So does this means I don't have to worry at all with Start Conditions? And then that I only need to check for the ACK response to continue with the code?

Clawson, I have already did this in AtMega328 in the past. I did it for learning about TWI by storing and reading simple values from an external memory chip.
Here the problem I think it is the fact that I don't know that much about TWI and Mega4808 that allow me to understand the User Manual instructions. And adding to that, seems to exists many new features that I don't know if I need them.

I'm ok with the eye candy way of microchip doing things and writing the header file because it's been easy ti find the register's names and by what is said in User Manual. That is the least of thr problems.

I gave the example of SDAHOLD that I read about what it is but I have no clue how to reason the option to choose in my case.

And yet about Mega328, because it is a more simple chip, datasheet ends up more easy ro understand. They ezplain things in a more linear way. I mean, chronologically speaking, is way easier to understand. They start in the beginning and go until the end without the need of explaining other things in the middle. Here, for Mega4808 they explain each feature but not like they organize explaining for TWI frim beginning to end. They explain featur 1, then they explain feature 2 and after they explain feature 3, but not that things needs to happen in the code by this order. That is a problem to me. I'll posr the code I have. Maybe you guys can help me from there.

Ok, I sent a support ticket to Microchip about the TWI interface and if it was possible for them to create a basic example guide on how to configure TWI for AtMega4808.

They told me there is a document I could use to try to figure it out because registers were written in the same way as for AtMega4808.

This document purpose is a little different from what I need it for but still is something. This document describes, if I'm not mistaken, a bootloader operation using TWI but in Slave mode!

So I started looking into the project files and I see that even if that is a basic and simple example, I think it's still a little complex to start with because they handle collisions and other stuff I was not interested in yet! And they are also using structs and enums to create data types that maks it a bit harder to "decode" so to speak! Ok it may be a bit more intuitive when you get used to it but for now it's not very user friendly yet (at least for me).

Anyway, I still tried to see what is happening at least inside the function that initialises the TWI interface and I might not be that far from what it is needed.

So their function is as follow:

static void init_twi(void)
{
	/* Switch pins to alternate TWI pin location */
	PORTMUX.CTRLB |= PORTMUX_TWI0_ALTERNATE_gc;

	/* Enable TWI driver */
	i2c_slave_init();
}

Then i2c_salve_init() is:

void i2c_slave_init()
{

	// TWI0.CTRLA = 0 << TWI_FMPEN_bp /* FM Plus Enable: disabled */
	//       | TWI_SDAHOLD_OFF_gc /* SDA hold time off */
	//       | TWI_SDASETUP_4CYC_gc; /* SDA setup time is 4 clock cycles */

	// TWI0.DBGCTRL = 0 << TWI_DBGRUN_bp; /* Debug Run: disabled */

	TWI0.SADDR = I2C_SLAVE_ADDRESS << TWI_ADDRMASK_gp /* Slave Address */
	             | 0 << TWI_ADDREN_bp;  /* General Call Recognition Enable: disabled */

	// TWI0.SADDRMASK = 0 << TWI_ADDREN_bp /* Address Mask Enable: disabled */
	//       | 0x0 << TWI_ADDRMASK_gp; /* Address Mask: 0x0 */

	TWI0.SCTRLA = 0 << TWI_APIEN_bp    /* Address/Stop Interrupt Enable: disabled */
	              | 0 << TWI_DIEN_bp   /* Data Interrupt Enable: disabled */
	              | 1 << TWI_ENABLE_bp /* Enable TWI Slave: enabled */
	              | 1 << TWI_PIEN_bp   /* Stop Interrupt Enable: enabled */
	              | 0 << TWI_PMEN_bp   /* Promiscuous Mode Enable: disabled */
	              | 1 << TWI_SMEN_bp;  /* Smart Mode Enable: enabled */

	TWI0.MCTRLA = 1 << TWI_ENABLE_bp;  /* Enable TWI Master: enabled, for bus error detection */
}

So, anyone willing to help me to go through this code and write my own code (an even mor simple version of this code just to make the TWI work)?

The code they sent me is here:

https://www.microchip.com/wwwApp...

Yes, I think I'm aware of that bit. The Slave device address is 0x18 so I'm adding (OR) 1 bit to the LSB of this address for read operation or 0 for Write operation. I have defined 2 macros like:

#define READ_OP (0x01 << 0x00)
#define WRITE_OP (0x00 << 0x00)

So, when I want to add/remove this bit I just use it like:

REGISTER = address | READ_OP;

or

REGISTER = address | WRITE_OP;

Now what I want is to try to use those 2 functions to try to build my own for my device!

Well, that's what I just learnt today from an IRC friend that taught me that. I changed it and i can see it's now correct, at least for the address part. I can see it with my scope I2C decoder.

I'll try to keep going tomorrow and figure out how to read temps from the sensor. I think I'm close.

I'm having more issues now with another setting that I decided to change.

In my Salve device datasheet there is this setting:

The Serial Port Clock Frequency says up to 400Khz so I decided to change the Master Device main clock frequency from 20Mhz to 20Mhz / 64 = 312.5Khz which is within Slave device range.

But the formula that my Master device datasheet says to use to evaluate this MBAUD value and that returned a value of 95 when I did the math for the first time assuming an f_SCL freqeucny of 100Khz is now returning a negative value for 312.5Khz.

Master device datasheet says:

So, the first time I used this formula I assumed an f_SCL= 100Khz, f_CLK_PER = 20Mhz (default Master device main clock frequency) and T_RISE = 2.5ns also from my Master device datasheet.

Here my unknown is BAUD and solving this in order to BAUD I get:

100Khz = 20Mhz / (10 + 2*BAUD + 20Mhz*2.5ns)

BAUD = 95 approx...

But now, I used a prescaler to bring my Master device main clock frequency to a value which would be within Slave device SCL frequency range. So I chose to use a 64 prescalor factor.

So, the above formula would become filled with the following parameters:

I assumed f_SCL = 20Mhz / 64 = 312.5Khz

312.5Khz = (20Mhz/64) / (10 + 2*BAUD + (20Mhz/64)*2.5ns)

BAUD = - 4.5

This is not reasonable and at this point I don't know what makes and what doesn't makes sense!

Ok, thank you for letting me know!

Can you also check about the latest problem I stated about the frequency setting?

So how can I possibly check that? I don't remember of reading anything like that in the datasheets I'm using.

I'm trying another version of my code.

I have worked around the f_SCL frequency and BAUD value and tried to send the address and read a single byte of data, then send NACK from Master and issue a Stop_Bit() and check what shows up on scope.

Thinks are not looking pretty for 2 reasons:

1st - I can't activate the Env. Table that shows the decoding results, if applicable.

2nd - I can't understand how to decode it by myself. I was expecting a specific number of bits and that those bits could tell me something more meaningful. But I can't fetch anything from it other than what the following picture shows (if I'm correct):

Thanks for confirming. In fact, the scope was confirming because the frequency is matching the math.

But after all, my code is still not working. I would need some help to try to figure out why.

I could post here all my code but to b honest the code tags are not very friendly so I was thinking about to create a Git repo and everyone could see and change the code.

I have one version of my code that is partially working but in my opinion it's not the most logically correct and then I have another version that I think it is logically more correct but that it's not working at all!

I'm not sure so I placed those 2 settings there!

In which code?

Well, I have to admit this is also my first time reading a datasheet and trying to do something from scratch so I might also misunderstanding many things in the datasheet. Probably for someone with some more experience than me, would find the datasheet pretty explanatory. But not me!

I need to keep digging!

I'm was even trying to split my TWI_Read() function line by line and add each line before the while() loop and use my scope in "Single" mode where it captures the first bits on SCL line to see if anything was going on, but when I place the line of code with the Slave address before the while(1) loop, I can only capture a single transition on SCL line from 0 to 1. Nothing else! I have also increased frequency to 20Mhz/8 and MBAUD to 7. This was supposed to return a frequency of about 104Khz but my scope says about 111Khz. Hope this is not critical!

I need to apologize but as I wait for answers here I'm always trying to change things, read and think about other possible interpretations and therefore, when people replies here and I see the replies, many of the times, my code is already way different than when I posted here my questions.

So, about the '!', of course I know it may change the code dramatically but by the time I read your reply, that '!' was already gone and probably the condition being tested was also different.

Anyway, about those schemes/pictures you posted, I think I understand the concept and the order things happens but turn it into code is another very different thing. That has been my struggle so far!

And Mr. @GermanFranz, you said you're no expert in C and you don't have to be. I'm not an expert in C at all. This is all about having some background on I2C, I mean, to have done this before and to be used reading datasheets! I'm not comfortable with any of them yet.

Just as a note and to give you some context on my (in)experience on the matter, I didn't even know that the way of coding the following directive - ADDRESS + R/W - was by means of a left shift and adding a bit to the LSB position. I interpreted this as adding (due to the '+' sign) 1 to the address of the slave device like 0x18 + 0x01 = 0x19. I now know this makes no sense but when I read ADDRESS+R/W, to me this was always a sum operation, 0x18 + 0x01, read operation, 0x18 + 0x00, write operation.

Anyway, a part from this, I'm more interested in figuring out how to make this work.

I wanted to understand why one of the versions of the code where I have the TWI_Read() function being called 256 times inside the while(1)  is working and I can see the Slave address being sent to the bus and being ACK by the Slave device and when I change the code so that the for loop with the 256 cycles goes inside the TWI_Read() function itself, I can no longer see the Slave address being sent to the bus and ACK by the Slav device.

I'm going to place both code online and paste here the links because it will be more easily readable!

Edited;

Code with 256 reads. This loop with 256 cycles is inside th while(1) loop in main() function. This version of the code is the only one where I can see on my scope the Slave address being sent to the bus and being ACK by the Slav address. However, I think this is not the correct way of doing things because it is not supposed that I send the Slave address in each one of the 256 reads. Datasheet shows I can perform as many reads as I like and Figure 24-7, page 339 here.

https://ideone.com/uG2KVT

Then I tried to change the code so that the Slave address wouldn't be sent in every one of the 256 loops, by moving this loop into the TWI_Read() function but despite the fact that I think I changed nothing in the way each setting is happening, I can't understand why I can't see a thing on my scope.

https://ideone.com/t6att5

The only thing I did was to adapt the 2nd version to have the 256 reads inside TWI_Read() function but with this code I can't see anything at all on scope!

This is where I need help to try to check where the problem might be.

This is not about C. There's nothing complex in the code. This is in fact all about settings and knowing about I2C/TWI. All C code here is just meaning of settings, knowing when and how to use them. Not anything related to C programming language!

Ok, my last post is asking about C but only because I can't spot any big change in the chronology of events and I was hoping someone to help me, but other than that, it's all about settings and I2C/TWI.

Hi.

I can understand the BUS State, State diagram. Translate it into code is another very different matter.

About the other picture, it's confusing to me at some points. I'll try to follow the picture and say how I translated it into code.

According to the picture description, light grey diamond shape is something that must be done with code. Dark grey is stuff related to bus state. So, having this said, I start looking to the picture and I see M1. I read about M1 and it is said that it's for a case of Arbitration Lost or Bus Error during Address Packet. But I don't understand this. How can this be an error during an Address packet if, at this point, and according to the picture provided, there is no address byte sent yet?

Same for M2 which is described as Address Packet Transmit Complete - Address not Acknowledged by Slave. There is no address packet sent yet so how they say that at M2 there is an address packet transmission complete and not ACK by the Slave device. No sense to me here either!

Again, for M3 which is described as Address Packet Transmit Complete - Direction Bit Cleared. How can the Address packet transmission to be completed if, according to the picture, the Address rectangle is yet to come? I can't understand this, at least until here.

Anyway, I tried to follow the diagram from the beginning, ignoring these 3 first cases. So, the first thing I see is that in my code, I have to wait until the BUS becomes IDLE. I do it with the following line of code inside my TWI_Read() function:

while((TWI0_MSTATUS & TWI_BUSSTATE_gm) != TWI_BUSSTATE_IDLE_gc)
      /*wait*/;

Then the picture says I need to issue a Start Bit/Condition. The datasheet says that when the TWI0_MADDR is written with the Slave address and the R/W bit, the Start Bit/Condition is automatically issued by the hardware.

So I do this with the following line of code:

#define READ_OP (0x01 << 0x00)

TWI0_MADDR = (0x18 << 1) | READ_OP;

So, at this point, I can save the ACK/NACK from the Slave device or just ignore it, I guess. I chose to save it. Or better, I'm returning it with the following lines of code:

#define STATUS_NACK 0x01

if(TWI0_MSTATUS & TWI_RXACK_bm)
      return STATUS_NACK; // Slave Address NOT received

TWI_RXACK is 0 if ACK is signaled by the Slave device and 1 if NACK is signaled.

After this, and if I understand the thing, the Slave device responded with the ACK/NACK and I can now read data bytes from the Slave device.

I assume that at this point I'm here in the picture:

Now I think it's time to read data bytes from the Slave device. Also here I'm not sure how it's done, but for some reason, I assumed that after the Slave device knows it will be performed a Read operation on the BUS that it will send it's data onto the BUS so that the Master device can fetch it from the BUS into it's TWI0_MDATA register, so I try to read with the following line of code:

*packet = TWI0_MDATA;

But I'm not sure this is the way to read data bytes from the Slave device or if I have to access some specific register directly from Slave device. I really don't know!

The, reading both the datasheet and this picture at the same time, I see that a transaction for a Master Read operation should obey the following frame:

My reasoning tells me about this picture, that in the case that I only need to read a single data byte, I must issue a NACK from the Master device to signal I don't want to read more data and after that, I must issue a Stop Bit/Condition.

And by looking to the picture with the 4 cases, M[1-4], I see that if everything goes smoothly, I'll go to either M4 or M2. I exclude M4 because it doesn't match the above picture of the Master Read frame format. I want to read only one byte of data, so I need to have a NACK followed by the Stop Bit/Condition. The only case that matches this situation is M2 but M2 was described as Address Packet Transmit Complete - Address not Acknowledged by Slave. So, what the hell? I'm not at an Address packet transmission right now. I'm at a Read data byte. No sense once more in my opinion. So I can't understand where am I going wrong. Despite all this, I'm issuing a NACK bit and a Stop bit/Condition from the Master device with the following lines:

TWI0_MCTRLB = TWI_ACKACT_NACK_gc;
TWI0_MCTRLB = TWI_MCMD_STOP_gc;

So, I acknowledge that I have ignored some aspects from that picture with the M cases and I think I have tried to follow the above frame format for a Master Read operation and still no data bytes can be fetched from the BUS by the Master device!

This is quite a bit of information to digest. I'll try to see what I would change in my code after reading your post.

This is going to be an endless journey of questions.

So you say that waiting for the BUS to become IDLE may not be enough and then you talk about BUSERROR or ARBLOST being set in MSTATUS. In such a case you suggest to turn OFF and then turn TWI ON again, right?

So, I'm using this:

while((TWI0_MSTATUS & TWI_BUSSTATE_gm) != TWI_BUSSTATE_IDLE_gc)
        /*wait*/;

to wait for the BUS to become IDLE. And handling BUSERROR and/or ARBLOST should be after or before waiting for the BUS to become IDLE?

Recover from BUSY back to IDLE, according to that State Machine diagram is only possible with a Stop Bit/Condition + Timeout. This is another thing not making sense to me. At the beginning of TWI section of the datasheet, it's said that TIMEOUT must be disabled for TWI operation.

Ok. I have to understand and re-write the code in such way I can re-Enable TWI device in the correct timing.

That I know. Thanks

That violation you refer to, is related with electrical interference and other phenomena not controlled by us or what kind of violation we might be talking? And btw, I'm using a small dev board so I'm not using wires or cables. So connections are what they are. The shortest possible, I presume!

Yeah, I have read that info many times also in the datasheet.

Nahhh... It's not working.

I0ve changed a few things but I can't see on scope what I was expecting.

I haven't seen that code yet. But to go through it I need also to take a look at that chip.

Ok, I guess I'll have to give it a try!

I kind of took some parts of that code and I can now see e few more things on my scope but I still think it's not correct what scope is showing!

My actual code:

https://ideone.com/4GVVf4

This is what my scope shows now:

Looks like the only correct thing is the address which is 0x18. In this code I was trying to read 5 times and average the value. But I'm not even sure if what I see here represents 5 reads and even if it does (I think there are 6 reads instead), why the sensor is telling 01, FF, FF, FF, FF? This doesn't looks correct at all. The 0x1D could be eventually correct but not all the others!

I made this work with the other guy code and a couple of changes!