This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

i2c communication problems

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. image description

Parents
  • 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?

Reply
  • 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?

Children
No Data
Related