i2c communication problems

RE: i2c communication problems

RK — Thu, 07 Jan 2016 01:11:27 GMT

Thank you for saving me from having to dig out my Atmel board (which proved to be a D21 I barely remember how to program) and try it for myself.

RE: i2c communication problems

billt79 — Wed, 06 Jan 2016 21:23:48 GMT

This one is solved now. Turns out there was a problem with the code in the ASF, i have not narrowed it down completely, but it is due to incorrect configuration of interrupts, even though the interrupts in question are the same across all SAM D devices. I found an app note which contained different code, after giving that a go and changing it a bit it worked fine. Thanks for all the help. Now to program it OTA

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 16:09:35 GMT

Thanks RK, that would be greatly appreciated, i feel like i have been banging my head on this one for way too long

RE: i2c communication problems

RK — Tue, 05 Jan 2016 16:07:06 GMT

Sounds like you got all the low-hanging fruit covered! I thought about using that chip for a project but it had just too few pins for what I needed. I'll have a rake around in my bits box, I think I have a D21 or a D20 or a .. something or other with SERCOM on it, if I get a few spare hours I'll see if I can make that work.

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 16:02:33 GMT

There is no example for the D09, but the hardware is there, and its near enough identical. I wish there was an example though. You are correct about the range, i have got it configured to address_mode_range, with mask as the bottom, and addr as the top, although i have tried both ways for the sake of it. even with a fixed address there is no ack. ten bit addressing is disabled, but i didn't think to check GENCEN, i will check that one later. There is no ASF example for this, i have modified it to do this. i am actually using a D10 currently, but there is very little difference between that and the D09 (an extra timer if i remember correctly), just there are no dev boards with the D09 yet, and all our boards will be using the D09 as it is cheaper. Thanks for clearing up the bit about the 9th clock, that was a bit confusing for me, as both the arduino and sw_master were producing it.

RE: i2c communication problems

RK — Tue, 05 Jan 2016 15:37:34 GMT

After the master has clocked out the 8th bit and the clock is low, it just waits to see if the slave ACKs by pulling SDA low, it doesn't actually need to clock until it sees that, it can wait. This also gives slow slaves a little time to ACK. So a 9th clock pulse isn't necessary until SDA goes low for the ACK. In this case the Atmel doesn't pull low, so that's the end of the transaction.

You said, right at the top, that the D09 is configured to accept any address. I still don't see an ASF example which does that. So you have ADDR 17..26 set to zero (that's ADDR.ADDRMASK), 1..10 set to 127 (that's ADDR.ADDR) and CTRLB.AMODE set to 0x02 to enable the range? Oh and 10bit addressing is off and GENCEN also off. If all those are the case then it should respond to any address. Most of the examples I've seen used a fixed address and there isn't even an I2C example for the D09 for some reason.

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 13:18:17 GMT

Thanks Ole, seems that the atmel is definately the perpetrator here. It is odd, as it seems to be configured and functioning correctly, it just never gets an address match. Looks like i will need to ask somewhere on an atmel forum. Although i am not sure how the Atmel could ack the nrf, if the 9th clock cycle is not present, but i have tried using a different master which has this 9th clock, and its still not working. I would like to use the newer driver, but based on our hardware and software requirements, and also the time, it is not possible for me to update the SDK and softdevice which is a shame. On newer things i will certainty be using the latest versions.

I haven't yet tried the twi_hw_master on any other slaves yet only the sw version, perhaps i should also try this first!

RE: i2c communication problems

Ole Bauck — Tue, 05 Jan 2016 12:34:43 GMT

The reason that the stop condition is not clocked out is because of a PAN fix in twi_hw_master which shuts down the twi peripheral during the last clock cycle when an error is received (for example NACK). Adding a delay of about one clock cycle (10us) before the shut down will fix this, but the problem here is that the atmel chip is not sending ACK. Since the SW driver works with other i2c peripherals, the problem is with the atmel chip. Get this to work first.

I also suggest to use nrf_drv_twi instead of twi_hw_master if it is possible, as the twi_hw_master is deprecated.

RE: i2c communication problems

RK — Tue, 05 Jan 2016 02:27:50 GMT

Clicking that link takes me still to a 180x100 image, the title on the page is actually "scope.png (180x100)"! It's not clickable either, not that I can see, so there's no full-sized one I can see. Not that I suspect it would help much.

I'm pretty sure the tw_hw_master works fine, it's even simpler than the sw one. I don't use it myself, I write the registers directly but it's the same thing in the end. The TWI hardware I've never had a problem with on the nrf51.

The only example I see for the D20 is the D20 bootloader, shame there isn't a simpler I2C slave test, the unit tests only test master mode so they don't help. I can only suggest setting up the simplest I2C project you can, perhaps one of the other SAM boards has a version you can modify although I don't see much.

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 02:01:38 GMT

I think you might be correct, but after countless caffeine fueled hours of getting something that should be simple working, i was beginning to think otherwise. Its a pain, because the uart driver from ASF worked first time with no changes. I just revived my arduino micro and its not working with that either, although the data on the scope looks ok, its looking like i might need some external pullups, which were not needed with the nrf. the avr must have weak internal pullups. Apologies for any time wasted, however it would still be useful to figure out what the problem with the twi_hw_master is, as all the boards with a SAM on them will have the rev 3 chips here is a direct link to that image, hopefully it works now. I have tried it on my laptop and desktop and it works on both. s15.postimg.org/.../scope.png

RE: i2c communication problems

RK — Tue, 05 Jan 2016 01:00:56 GMT

I still can't open it on either browser - don't know why. Since I2C is pretty simple and you have it working with other peripherals, I have to think it being a problem on the D20 is most likely. Atmel is very clever with their ASF which is macro'ed and indirected so it sort of looks the same whatever board you're using, but it's very easy to make a mistake if you change even one line .. or sometimes no lines at all. Just getting success from the setup is not- regrettably, a guarantee of success. I get reasonably depressed every time I start a new ASF project because it takes so long to get the basics going and I always, ALWAYS mess one tiny thing up.

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 00:36:54 GMT

Also i am not sure why the picture is messed up for you, it is actually 1168*544px. Open it on its own and download it, postimage don't seem to have modified it.

RE: i2c communication problems

billt79 — Tue, 05 Jan 2016 00:25:30 GMT

I will try it with an arduino,although i will need to pick on up. The code i am using is an example from the ASF, and is configured just fine. There are only 2 sets of pins which work with i2c. i have also tried the default ones in the example application but i would like to use the other two. The Atmels do have a large amount of config required, however most of what i need is default anyway, so all i have to do is get the defaults, and then modify what i need and then initialise, this seems to be working fine, returns status_ok. The i2c driver on the atmel is currently running in polled mode, so i disabled the timeout so it infinatley waits for a packet, but the flags never fire. Also there is good reason to be using the bit bashing code, as we have some specific requirements and half our boards are the rev1 chips. only recently did we get a new batch with rev3.

RE: i2c communication problems

RK — Tue, 05 Jan 2016 00:09:43 GMT

A 120x100px image of the screen isn't really going to help anyone help you. That's about the size of a postage stamp.

97kHz vs 100kHz, totally irrelevant, I2C is a clocked protocol, the actual clock rate (as long as within spec for, and configured correctly on, the other side) can vary massively. So its not that.

I don't know why ANYONE still uses the twi_sw_master code when the nrf51 series have wonderful working TWI hardware on them. That ancient bit banging code was, I think, to work around revision 1 problems.

How do you know you have the Atmel set up correctly? I do some Atmel programming and nice as they are, they sure have a LOT of configuration options for the serial ports. You need to make sure it's clocked, it has the correct hi/lo configs and you've used the right pins corresponding to the port you want. Do you have the Atmel working with a different master?