i2c communication problems

[billt79]

Hi,

I have been having a lot of problems communicating with an Atmel SAM D09 as a slave, and an nrf51422 as a master.

I seem to have two problems, hopefully solving just one will get me where I need to be. but I can't seem to narrow it down. The first issue, I have been trying to use a slightly modified twi_sw_master.c to communicate with the slave, this has worked with plenty of other i2c devices out there, like EEPROMs Acelerometers, and PMICs however the Atmel won't ack. The reason I believe this to be a problem, is it doesn't run at exactly 100Khz (best i can get is 94Khz), this seems highly unlikely to me, but it is the only thing that is apparent as the Atmel is returning no error while polling the interrupt flags, and all the config is set as required. It is also pulling up both of its i2c pins, which would indicate that it is working. I have done plenty of debugging with uart, and all seems normal.

To get around this i have tried using twi_hw_master.c to work, and i do get 100Khz exactly, however the waveform i see on my scope looks wrong. To my understanding, there are 9 clock pulses on SCL, the last one being for an ack/nack, this was present on the sw version, but on the hw version it is not present and there also does not appear to be a valid stop condition, although no data is being transferred due to the lack of an ack. My aim is to use the self programming function of the Atmel SAM to update it OTA via the BLE on the nrf. the code on the Atmel is from the ASF, so i can be quite sure it works. Also worth noting that the Atmel chip is configured to respond to any address between 0-127 regardless. Unfortunately for me i am very restricted on GPIOs on the nrf, so using something else is out of the question.

[RK]

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?

[billt79]

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.

[billt79]

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.

[RK]

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.

[billt79]

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